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Preface 


The  purpose  of  this  study  was  to  provide  those  Air  Force 
officials  concerned  with  the  research  and  development/ 
systems  acquisition  process  with  information  about  the 
communication  of  systems  requirements  from  the  end-user  to 
the  system  program  office.  The  immediate  objective  of  this 
research  is  to  identify  the  factors  which  are  related  to  the 
successful  communication  of  requirements,  but  it  may  be 
applicable  to  other  areas  of  the  acquisition  process  as 
well. 

In  performing  this  research  and  writing  this  thesis  I 
had  a  great  deal  of  help  from  others.  I  am  deeply  indebted 
to  my  thesis  advisor,  Major  William  R.  Hitzleberger ,  for  his 
continuing  support  and  effort  to  keep  the  focus  of  this 
project  on  the  process  and  results.  I  also  wish  to  thank  my 
wife  Captain  Linda  Smariga,  also  a  graduate  student  at  AFIT, 
for  her  unending  support  and  patience  over  the  sixteen 
months  we  spent  completing  this  program,  together. 


Russell  B.  Smariga 
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Abs  tract 

Air  Force  acquisition  program  management  officers 
(n=292)  were  surveyed  to  determine  which  factors  in  the  user 
to  system  program  office  requirements  communication  process 
were  related  to  achieving  effective  communication.  Using 
command  representatives  (n=17>  working  at  Aeronautical 
Systems  Division  were  also  contacted  to  provide  their 
perspective  of  the  communications  process.  Results  obtained 
from  reading  the  comments  on  the  questionnaires  and  from  the 
interviews  indicated  that  both  program  managers  and  user 
representatives  believed  that  additional  operational 
experience  on  the  part  of  acquisition  management  personnel 
would  enhance  the  requirements  communication  process.  The 
analysis  of  the  data,  however,  did  not  support  this. 
Operational  experience  of  the  program  manager  was  not 
statistically  related  to  any  of  the  measures  of  succussful 
communications . 

Program  managers  who  had  completed  AFIT  Systems  100 
tended  to  have  a  more  positive  outlook  on  both  the 
desirability  of  having  a  user  representative  in  the  SPO,  and 
of  the  overall  requirements  communication  process.  This 
relationship  was  not  present  for  any  other  single 
acquisition  management-related  course. 
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The  results  indicate  that  no  single  factor  contributes 
significantly  to  the  success  or  failure  of  the  systems 
requirements  communication  process. 


m 


THE  COMMUNICATION  OF  THE  USER'S  REQUIREMENTS 


TO  THE  SYSTEM  PROGRAM  OFFICE  DURING  THE  ONGOING 
SYSTEM  DEVELOPMENT  PROCESS 

! 

I.  Introduction 

Background 

The  purpose  of  the  Air  Force  weapon  system  acquisition 
process  is  to  develop,  produce  and  deliver  to  the  field  a 
logistically  supportable  end-product  which  not  only  works, 
but  also  meets  the  specific  validated  need,  or  alleviates 
the  particular  deficiency  which  prompted  the  initial 
development.  The  weapon  system  acquisition  process  is 
influenced  by  many  factors  such  as  funding  availability, 
funding  stability,  cost  stability,  schedule  constraints,  and 
stability  of  program  requirements.  One  of  the  most  important 
influences  on  the  success  of  a  program  is  the  stability  of 
the  requirements  which  are  placed  on  the  program,  both  in 
terms  of  quantity  required  and  specific  performance 
requirements.  Successfully  defining  specific  performance 
requirements  implies  active  communication  between  the  System 
Program  Office  (SPO)  and  the  user  of  the  system.  One  of  the 
most  difficult  tasks  which  the  program  manager  is  charged 
with  in  today's  defense  system  acquisition  environment  is 
the  successful  interpretation,  as  seen  from  the  user's 


viewpoint,  of  the  initial  set  of  requirements.  Just  as 
important  as  initial  requirements  interpretation  is  the 
ongoing  system  development  process  during  which  the  program 
manager  must  ensure  that  the  user's  requirements  are  being 
properly  implemented.  A  key  part  of  this  validation  process 
is  the  frequent  participation  by  the  user  in  the  development 
process.  "How  are  the  user's  detailed  performance  require¬ 
ments  addressed  throughout  the  on-going  system  development 
process?”  is  an  important  question  to  be  addressed  if  the 
acquisition  process  is  to  be  as  efficient  as  possible. 

Statement  of  Problem 

In  answering  the  general  question  posed  above,  the 
specific  problem  addressed  in  this  study  is  the  identifi¬ 
cation  of  the  factors  which  contribute  to  the  successful 
communication  of  the  user's  requirements  to  the  SPO,  and  to 
the  implementation  of  those  requirements  into  the  ongoing 
system  development  process. 

Investigative  Questions 

In  addressing  this  specific  problem,  the  following 
questions  were  considered. 

1.  How  are  most  of  the  communications  between  the  SPO 
and  user  conducted,  e. g. ,  by  message,  phone,  etc.? 

2.  How  frequently  do  the  SPO  and  user  communicate? 

3.  Do  most  communications  follow  formal  or  informal 


command  channels? 


4. 


Does  SPO  and/or  user  acquisition  experience 


contribute  to  better  communication? 

5.  Does  having  operational  experience  (or  the  lack  of 
it)  effect  the  program  manager’s  ability  to  effectively 
interpret  and  implement  requirements? 

6.  Does  physical  separation  of  the  SPO  and  the  user's 
main  operating  location  interfere  with  communications? 

7.  Do  travel  constraints  such  as  limited  TDY  funding 
interfere  with  communications? 

Scope 

This  research  studied  the  population  of  program  and 
project  managers  at  all  major  Air  Force  Systems  Command 
< AFSC)  product  divisions.  Data  collected  included  infor¬ 
mation  on  the  current  state  of  communications  between  the 
SPO  and  the  end  user  of  the  system  in  the  field,  techniques 
used  in  this  process,  and  the  overall  effectiveness  of  the 
process.  The  study  also  collected  information  from  a  small 
number  of  user  representatives  serving  at  Aeronautical 
Systems  Division  (ASD). 

Limitations 

This  study  drew  the  largest  portion  of  data  from  active 
duty  Air  Force  officers,  0-2  through  0-5,  who  either 
currently  work  in  a  27XX  position,  or  have  in  the  immediate 
past  worked  in  a  27XX  position.  The  population  was  further 
limited  in  that  only  data  from  individuals  who  had  at  least 
six  months  experience  in  a  27xx  position  were  considered, 


and  only  those  managers  who  were  stationed  within  the 
continental  United  States  were  considered. 

Representatives  of  the  operational  using  commands, 
including  Military  Airlift  Command  (MAC) ,  Strategic  Air 
Command  (SAC),  and  Tactical  Air  Command  (TAC),  currently 
serving  in  liaison  positions  at  ASD  provided  information  on 
how  the  user  views  the  current  requirements  communication 
process . 

The  study  does  not  include  any  perceptions  of  those 
officers  who  are  serving  as  program  managers  with  28XX 
AFSC's  at  Electronic  Systems  Division  (ESD),  but  does 
include  information  from  27XX  program/project  managers  at 
ESD. 

Specifically  excluded  from  this  study  was  the  initial 
definition  of  requirements  for  the  development  process. 
Initial  definition  of  requirements  includes  the  initial 
statement  of  a  need  by  the  user,  the  development  of  the 
Statement  of  Operational  Need  (SON)  and  the  complete 
requirements  validation  process.  This  study  only  addressed 
the  communication  process  between  the  user  and  the  SPO 
subsequent  to  the  issuance  of  a  program  management  directive 
from  HQ  USAF  to  HQ  AFSC. 

The  conclusions  drawn  from  this  study  are  based  on  self- 
reported  data  provided  by  individual  Air  Force  officers 
connected  with  the  research  and  development  systems 
acquisition  process. 


It  is  assumed  that  the  personnel  involved  in  the 
acquisition  process  to  be  randomly  selected  for  this  study 
have  a  basic  understanding  of  the  communication  channels  and 
techniques  available  to  them  within  the  limits  of  Air  Force 
regulations  and  individual  program  constraints  such  as 
funding  limitations  or  special  security  restrictions.  Since 
all  of  the  program/project  managers  in  this  study  are 
officers,  and  have  at  least  six  months  experience  as 
program/project  managers,  this  assumption  should  be  valid. 
This  should  also  be  a  valid  assumption  for  all  of  the  user 
representatives  who  participated. 

Definitions 

Acquisition  Program.  A  defined  effort  funded  by 
research,  development,  test  and  evaluation  ( RDT&E)  and/or 
procurement  appropriations  with  the  express  objective  of 
providing  a  new  or  improved  capability  in  response  to  a 
stated  mission  need  or  deficiency. 

Program  Element  Monitor.  The  person  within  the  HQ  USAF 
office  of  primary  responsibility  who  is  directly  responsible 
for  a  given  program  and  all  documentation  necessary  to 
harmonize  the  program  in  the  budget. 

Program  Management  Directive.  The  official  HQ  USAF 
management  directive  used  to  provide  direction  to  the 
implementing  and  participating  commands  and  satisfy 
documentation  requirements.  It  will  be  used  during  the 


entire  acquisition  cycle  to  state  requirements  and  request 


studies,  as  well  as  initiate,  approve,  change,  transition, 
modify  or  terminate  programs. 

Program  Manager.  The  individual  in  the  DoD  chartered  to 
execute  all  functions  necessary  for  the  development  and 
purchase  of  a  defense  system. 

Project  Manager.  A  project  manager  is  usually  respon¬ 
sible  for  a  sub-component  of  a  larger  system  and  reports 
directly  to  a  program  manager. 

Statement  of  Operational  Need.  A  formal  numbered 
document  used  to  identify  an  operational  deficiency  and 
state  the  need  for  a  new  or  improved  capability  for  US  Air 
Force  forces. 

SPO  Director.  A  SPO  director  is  the  overall  chief  of  a 
System  Program  Office.  If  the  SPO  is  a  single  system  SPO 
then  the  SPO  director  is  probably  also  considered  the 
program  manager. 

System  Acquisition  Process.  The  system  acquisition 
process  is  defined  as  a  sequence  of  events,  beginning  with 
the  determination  that  an  unfulfilled  mission  need  exists, 
and  extending  through  research,  development  and  production 
of  a  system,  to  the  operational  use  of  that  system. 

System  Program  Office.  The  office  of  the  program 
manager  and  the  point  of  contact  with  industry,  Government- 
agencies  and  other  activities  participating  in  the  system 
acquisition  process. 


II. 


Literature  Review 


Introduction 

This  literature  review  is  the  foundation  for  the  study 
of  the  on-going  communication  of  system  requirements  from 
the  user  to  the  SPO  and  the  continued  refinement  of  require¬ 
ments  throughout  the  system  acquisition  process.  The  purpose 
of  this  review  is  not  to  provide  a  review  of  all  the  commun¬ 
ication  methods  available.  Instead,  the  purpose  is  to 
review  literature  which  addresses  factors  such  as  cost 
stability,  personnel  quality,  defense  contractor  involve¬ 
ment,  and  outside  agency  involvement  to  provide  a  view  of 
the  complex  framework  in  which  SPO/user  communications  take 
place. 

The  requirements  development  process  can  be  facilitated 
by  involving  people  who  are  knowledgeable  in  the  applicable 
mission  area  for  the  system.  Frequently,  the  most 
knowledgeable  people  are  those  who  will  be  working  with  the 
system  once  it  is  fielded,  i.  e. ,  the  users.  However,  since 
the  users,  in  most  cases,  are  not  located  with  the  SPO’s, 
communication  between  the  two  is  difficult  and  development 
of  the  statement  of  mission  requirements  is  hindered. 


Discussion  of  the  Literature 

The  information  available  on  user  interaction  during  the 
development  process  comes  almost  exclusively  from  civilian 
literature  because  civilian  business  organizations  must  rely  || 


heavility  on  successfully  defining  and  satisfying  customer 
(user)  requirements. 

The  environment  in  which  Department  of  Defense  acquisi¬ 
tion  programs  must  be  managed  is  an  extremely  complex  one 
where  many  influences,  both  internal  and  external  to  the 
program,  contribute  to  program  stability  and  to  the  overall 
success  or  failure  of  the  program.  Of  particular  importance 
in  establishing  program  stability  are  funding  and  cost 
stability,  personnel  quality,  defense  contractor  involve¬ 
ment,  and  user  involvement  in  the  development  and  continued 
refinement  of  system  requirements. 

Funding  and  Cost  Stability.  The  high  attention  level 
that  money  and  money-related  topics  command  in  the  public 
eye  forces  all  personnel  involved  in  program  management  to 
pay  particular  attention  to  the  cost  figures  associated  with 
their  programs.  According  to  Jacques  S.  Gansler  achieving 
success  in  money  related  areas  in  program  management  is 
dependent  on  at  least  two  things:  congressional  funding 
stability;  and  accuracy  of  initial  cost  estimates  (6:3,7). 

Funding.  Stability  of  congressional  funding 
levels  is  important  because  when  Congress  projects  that  a 
certain  amount  of  money  will  be  available  for  a  certain 
program,  that  program's  acquisition  strategy  is  shaped 
accordingly.  Gansler  says  that  the  acquisition  strategy  on 
most  programs  contains  back-up  plans  in  case  funding  levels 
are  reduced,  but  the  implementation  of  these  back-up  plans 
usually  results  in  greater  overall  program  costs  (6:4). 


When  Congress  does  reduce  funding  levels,  even  if  only  for  a 
short  period  of  time,  programs  are  stretched  over  a  longer 
period.  This  alternative  is  usually  chosen  instead  of 
lower-priority  programs  being  canceled.  This  results  in 
higher  overall  program  costs  and  "because  the  quantities  of 
equipment  being  produced  in  any  one  year  are  smaller,  their 
unit  costs  rise"  (6:4).  Stanley  Baumgartner  agrees  "stabil¬ 
ity  in  funding  is  also  essential"  (2:32). 

Cost.  In  Baumgartner’s,  one  of  the  key  measures  of 
the  success  of  any  DoD  program  is  whether  or  not  it  "meets 
cost  objectives"  (2:32).  One  condition  necessary  to  meet 
cost  objectives  is  to  have  the  stability  in  funding  levels 
described  above.  A  second  necessary  condition  is  to  have  an 
honest,  realistic  initial  cost  estimate  (6:7).  If  the 
initial  cost  estimate,  against  which  the  program  will  be 
judged,  is  too  optimistic,  the  chances  of  meeting  the  cost 
goals  are  very  low.  Many  programs  are  initially  estimated 
low  to  help  ensure  that  they  will  be  approved,  but  then  end 
up  costing  much  more  due  to  "inefficiencies  caused  by 
program  instability  and  stretchout”  (6:7). 

General  Mullins  expands  the  idea  of  cost  to  include  the 
entire  life  cycle  of  a  program  (7).  He  suggests  that  by 
allocating  a  small  portion  of  the  money  for  production  units 
of  a  system  to  support-related  items,  the  U.  S.  could  have  a 
significantly  enhanced  fighting  force,  which  is  "combat- 
ready"  (7:4). 


Personnel  Quality.  If  inanimate  influences  such  as 
funding  and  cost  have  such  a  great  impact  on  program 
success,  it  follows  that  the  people  involved  should  have  an 
even  greater  impact.  In  a  survey  of  managers  of  successful 
programs,  three  staff  members  at  the  Defense  Systems  Manage¬ 
ment  College  (DSMC) ,  including  Stanley  Baumgartner,  found 
that  one  of  the  most  frequently  cited  contributors  to 
program  success  was  the  quality  of  personnel  (2:32).  LtCol 
William  Smith  states  that  "programs  are  run  by  people,  and 
the  better  people  C  the  program  manager]  can  attract,  the 
better  the  program  will  be  managed”  (12:25).  LtCol  Smith 
also  suggests  that  success  breeds  success  when  he  states 
that  "the  most  successful  program  manager  attracted  good 
people,  provided  the  guidelines  .  .  .  and  let  them  act” 

(12:25).  Boar  agrees  that  quality  people  "contribute  to  the 
success”  (3:31)  of  a  project. 

According  to  R.  A.  Robinson,  not  only  must  personnel 
involved  with  a  program  be  of  good  quality  for  the  program 
to  be  successful,  they  must  have  a  good  leader  to  imitate 
(11:27).  Employees  must  all  know  the  goals  of  the  program, 
and  know  that  "success  of  the  total  program  [means]  personal 
success"  (12:25).  Mr.  Robinson  carries  this  to  the  extreme 
when  he  says  that  in  a  successful  operation  "all  employees 
are  operating  according  to  the  same  set  of  beliefs,  in  much 
the  same  way  followers  of  a  particular  religious  faith 
adhere  to  the  same  beliefs”  (11:26). 


Defense  Contractor  Involvement.  Quality  of  personnel 
is  as  important  on  the  civilian  contractor's  program  team  as 
it  is  on  the  government's  side.  Stanley  Baumgartner  states 
that,  "with  few  exceptions  all  C program  managers  of  success¬ 
ful  programs]  characterized  their  contractors  as  being  very 
good  or  excellent”  <2: 35).  An  important  ingredient  in 
program  success  is  "openness  and  frankness  on  the  part  of 
the  Cprogram  manager]  and  his  industry  counterpart"  (2:35). 
To  lead  to  success,  Boar  says  this  openness  must  provide  the 
development  contractor  with  a  full  understanding  of  "user 
needs"  (3:25). 

One  interesting  point  concerning  contractor  involvement 
in  the  system  development  process  is  brought  out  by  General 
Mullins. 

Under  the  current  arrangement,  then,  the  contrac¬ 
tor  validates  the  results  of  his  independent 
research  through  marketing  briefings  to  the  using 
commands;  when  such  briefings  lead  to  a  contract 
award,  the  contractor  has,  in  effect,  created  a 
requirement.  In  reality,  weapons  capabilities 
influence  military  requirements,  and  prime  con¬ 
tractors  develop  weapons  capabilities  (7:4). 

General  Mullins  implies  that  contractors  do  not  always  have 

the  best  interests  of  DoD  in  mind,  and  that  DoD  must  work 

harder  to  influence  contractors  in  early  stages  of  their 

involvement  with  any  program  or  concept  (7:4-6). 

User  Involvement  in  Requirements  Definition.  The  ideal 
combination  of  stable  funding  levels,  stable  program  costs, 
high  quality  DoD  personnel  and  dedicated  contractor 
personnel  will  not  lead  to  success  if  the  requirements  of 


the  user  are  not  both  clearly  stated  and  clearly  understood 
by  all  involved.  This  communication  of  the  user's  require¬ 
ments  to  the  developer  is  the  common  theme  which  links 
together  all  of  the  literature  in  this  review.  LtCol  Smith 
states,  "the  user  connection  is  all  important”  (12:25).  Boar 
adds  that 

The  solution  to  the  communication  problem  was 
never  to  make  everyone  a  professional  specifier, 
but  to  permit  everyone  to  review  specifications 
in  a  familiar  medium  (3:31). 

Boar  suggests  that  this  "familiar  medium"  (3:31)  should  be  a 
prototype  of  the  working  system,  which  would  allow  user  to 
evaluate  the  system  hands-on  and  provide  meaningful  feedback 
(3:25,27,29).  Gansler  says  that  it  is  important  for  the 
user  to  be  as  close  as  possible  to  the  developer,  and  that 
user  requirements  be  established  early  and  adhered  to 
throughout  the  program  (6:8,10).  "Typically,  a  successful 
program's  requirements  have  been  established  early  .  .  .  and 

requirements  stay  virtually  intact  throughout  a  particular 
phase  of  a  program”  (2:37).  it  is  informative  to  review 
civilian  literature  related  to  satisfying  the  customer, 
because  the  only  way  product-oriented  businesses  satisfy 

customers  is  by  providing  products  (systems)  which  are 

\ 

responsive  to  users'  needs.  Speaking  from  the  civilian 
sector,  Mr.  Robinson  shows  that  industry  considers  user 
needs  important  also  by  stating,  "with  each  employee  acting 
on  the  wants  of  the  customer  .  .  .  CaJ  company  will  make 
more  productive  use  of  resources”  (11:27). 


Furthering  this  idea  is  William  G.  Ouchi  who  states 
that  a  key  objective  of  the  organization  is  "To  serve  as  the 
customers’  purchasing  agent  in  fulfilling  their  needs  and 
expectations  for  merchandise  and  services"  (8:137-138). 

David  Packard  says  that  a  key  objective  must  be  ”To  provide 
products  and  services  of  the  greatest  possible  value  to  our 
customers”  (8:227).  A  further  Hewlett-Packard  objective  is 
that  "Good  communication  should  be  maintained  with  the 
customer”  (8:228).  Tom  Peters  makes  the  point  that  it  is 
important  to  involve  the  customer  at  every  step  by  asking 
the  questions  "Does  the  customer  know  how  hard  you  are 
working  for  him/her  (via  what  mechanisms,  how  assiduously 
practiced)?”  (10:89),  and  ”Do  you  have  any  'simple'  rituals, 
like  .  .  .  weekly  calls  to  ask  'How  are  we  doinq  for 

you? ' ” ( 10: 105) .  Peters  quotes  one  unidentified  successful 
company  president  as  saying  "'.  .  .  you've  gotta  be  in 

touch.  You’ve  gotta  press  the  flesh.  You've  gotta  show  the 
flag.  Somehow.  .  .  .  But  being  out  of  touch  is  bad  news'” 

(10:106).  Peters  states  that  a  key  to  success  in  a  company 
or  on  a  project  is  to  make  sure  that  "Visits  with  customers 
are  exchanged  regularly,  at  all  levels  in  the  company  and 
customer  organization"  (10:125).  He  says  that  these  ’’Visits 
to  customers  and  time  spent  with  them  should  never  run  less 
than  30  percent  for  senior  line  management,  and  not  less 
than  10  percent  for  indirect  function  management”  (10:127). 
Another  way  of  conveying  Tom  Peters  ’  view  of  the  importance 
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of  customer  involvement  is  his  idea  of  how  a  poorly  managed 
operation  is  run. 

People  stored  away  in  little  cubbyholes,  hundreds 
of  miles  from  the  scene,  follow  a  precise  manual 
and  escalate  their  response  according  to  the 
manual's  definition  of  the  customer’s  need.  The 
only  problem  is,  they  never  tell  that  customer  just 
how  hard  they're  working  for  him  or  ask  him  if  the 
response  meets  his  definition  of  the  need  (10:85). 

Tying  these  concepts  back  to  the  DoD  acquisition 

management  system,  LtCol  Ronald  J.  Penick  states  that 

If  these  organizations  [users  and  other  related 
agencies]  are  involved  in  development  of  the 
initial  [program]  plan  they  become  committed  to 
the  program  and  will  support  it  with  considerably 
more  enthusiasm  than  they  will  if  asked  to  join 
the  team  later  (1:191). 

Speaking  from  the  user's  viewpoint.  General  Sir  Martin 

Farndale,  a  NATO  commander,  delineates  operational  tactics 

for  the  European  theater,  and  devotes  almost  as  much  space 

to  stating  equipment  and  personnel  requirements  as  he  does 

to  the  actual  description  of  tactics  (5).  General  Farndale 

goes  a  step  further  in  the  requirements  definition  process 

by  giving  additional  information,  in  the  statement  below, 

which  aids  in  setting  the  relative  priority  of  the 

requirements  he  stated  previously  in  the  article. 

Although  I  have  listed  several  improvements  to 
equipment  which  are  needed,  both  now  and  in  the 
future,  this  is  not  to  say  that  the  operation 
cannot  be  carried  out  now.  It  can,  but  the  equip¬ 
ment  I  mention  is  needed  to  enhance  our  offensive 
capability  so  that  we  can  carry  it  out  more  effec¬ 
tively.  It  is  also  necessary  to  enable  us  to 
keep  up  with  the  developing  threat  (5:9). 

On  the  other  hand,  also  writing  as  a  user,  General  Mullins 

conveys,  in  the  following  quotation,  that  the  process  is  not 


yet  perfect,  and  is  sometimes  hindered  by  the  users 
themselves . 

Nor  have  we  always  done  a  good  job  of  articulating 
the  requirement,  often  hitting  the  system  program 
managers  with  ’’second-thought ”  or  ’’after-the-fact” 
needs  <  7: 5) . 

Gansler  shows  that  this  difficulty  in  firmly  establishing 
requirements  often  leads  to  program  instability  (6). 

Finally,  the  President's  Blue  Ribbon  Commission  on 
Defense  Management  reinforces  the  overall  idea  that  the 
appropriate  system  acquisition  model  to  pattern  the  DoD 
after  is  that  which  results  from  studying  "successful 
programs  from  private  industry”  (9:11).  One  of  the  under¬ 
lying  features  of  the  successful  programs  to  be  emulated  is 
solid  communication  with  the  user.  The  report  to  the 
President  presents  the  following. 

Communication  with  users.  A  commercial  program 
manager  establishes  a  dialogue  with  the  customer, 
or  user,  at  the  conception  of  the  program  when  the 
initial  trade-offs  are  made,  and  maintains  that 
communication  throughout  the  program.  Generally, 
when  developmental  problems  arise,  performance  trade¬ 
offs  are  made  -  with  the  user's  concurrence  -  in 
order  to  protect  cost  and  schedule.  As  a  result,  a 
program  manager  is  motivated  to  seek  out  and  address 
problems,  rather  than  hide  them  (9:50). 

The  report  carries  this  idea  of  closeness  to  the  customer 

throughout  its  analysis  of  the  acquisition  process.  In  a 

statement  about  a  proposal  to  create  a  separate,  single 

Defense  Acquisition  Corps  the  report  states  that 

Because  C the  proposal]  would  have  the  undesirable 
result  of  putting  too  much  distance  between  acqui¬ 
sition  programs  and  users,  .  .  .  we  do  not  support 
the  proposal  in  its  full  form  (9:67). 


AS 
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Conclusion 

System  acquisition  program  stability,  both  in  the 
Department  of  Defense  and  in  the  civilian  sector,  is  depen¬ 
dent  on  several  factors.  Stable  funding  levels  must  be  set 
and  maintained  by  Congress.  Along  with  stable  funding 
levels,  program  costs  must  be  maintained  within  established 
limits.  The  quality  of  government  and  contractor  personnel 
associated  with  a  program  is  at  least  as  important  to 
program  stability  as  funding  and  cost. 

Even  if  all  of  the  above  factors  are  in  place,  a  program 
will  not  remain  stable  and  be  successful  unless  a  clear 
definition  of  what  the  user  wants  is  understood  by  all 
parties  involved  in  the  acquisition  process.  One  basic 
conclusion  which  can  be  drawn  from  the  literature  is  that  to 
develop  and  maintain  this  clear  understanding  of  require¬ 
ments,  the  user  must  be  actively  involved  in  the  system 
development  process.  Keeping  the  user  involved  requires  that 
program  office  and  contractor  personnel,  as  well  as  the 
user,  be  willing  to  maintain  open,  active  communications,  so 
that  the  best  possible  system  is  delivered  to  the  field. 


III.  Methodology 


Introduction 

This  chapter  outlines  the  methodological  approach  to  the 
research  problem.  It  presents  the  justification  for  survey, 
and  describes  the  survey  instrument,  pilot  study,  popula¬ 
tion,  assumptions,  and  analytical  method. 

Synopsis.  The  methodology  used  to  solve  the  stated 
research  problem  began  with  a  thorough  review  of  applicable 
literature.  A  survey  instrument  was  then  developed.  The 
draft  survey  was  administered  to  two  AFIT  Systems  400 
classes  to  form  the  basis  for  a  pilot  study,  which  helped 
refine  and  clarify  the  instrument.  The  final  survey  instru¬ 
ment  was  distributed  to  a  randomly  selected  sample  taken 
from  the  population  of  Air  Force  program/project  managers 
( AFSC  27XX) ,  First  Lieutenant  through  Lieutenant  Colonel. 
Sample  size  was  determined  using  the  HQ  USAF/ACM  guide  for 
developing  surveys,  and  numbers  of  officers  currently  ser¬ 
ving  with  duty  AFSC’s  of  27XX,  provided  by  the  ATLAS  Data¬ 
base.  Once  the  data  were  collected  they  were  statistically 
analyzed  via  several  methods.  A  convenience  sample  of 
representatives  from  using  commands  (MAC,  SAC,  TAC)  was 
taken  from  personnel  currently  assigned  to  the  using  command 
Systems  Offices  at  ASD.  These  personnel  provided  their 
views  on  a  limited  set  of  issues  related  to  the  requirements 
communication  process.  Finally,  results  of  the  study  were 


presented  and  recommendations  were  made  for  further 
research. 


Justification  for  Survey 

A  survey,  distributed  by  mail,  was  chosen  as  the  best 
way  to  collect  the  data  required  within  the  time  constraints 
of  this  research  project.  An  alternate  method  for  collec¬ 
ting  the  data  would  have  been  to  conduct  personal  inter¬ 
views,  but  due  to  the  time-consuming  nature  of  this  process 
the  sample  size  which  would  have  resulted  would  have  been 
too  limited  to  provide  any  generally  applicable  insights.  A 
limited  number  of  personal  interviews  were  conducted  with 
user  representatives  so  that  their  perspective  could  be 
presented.  Due  to  the  dispersed  nature  of  user  represen¬ 
tatives  working  as  program  liaisons  in  the  field,  a  large- 
scale  survey  of  these  personnel  was  not  practical. 

Instrument/ Pi lot  Study 

The  survey  instrument  was  designed  to  collect  both 
standard  demographic  data,  program  related  data,  and  data 
descri-  bing  frequency  of  communications  between  the  SPO  and 
user,  method  of  communication,  number  of  requirements 
changes  which  have  been  implemented  on  the  program,  and 
other  program  related  data.  Demographic  data  collected 
include: 

Rank 

Academic  Degree (s)  held 

Major  Academic  Field  of  Study 

Years  of  Service 

Years  of  Program  Management  Experience 
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Professional  Military  Education 
Professional  Program  Management  Training 
Current  Product  Division 
Current  Position  (SPO  Director, 

Program  Manager,  Project  Manager) 
Number  of  People  Directly  Supervised 
Role  in  Decision  Process 


Program  related  data  collected  include: 

Dollar  Value  of  Current  Program 
Current  Phase  of  Program 
Type  of  SPO  which  Program  is  a  part  of 
(Single  System  SPO,  Basket  SPO) 

User  Location  (ConUS,  OConUS,  etc.) 

Presence/ Absence  of  User  Representative 
in  SPO 

SPO/user  communication  data  collected  include: 

Frequency  of  Communication 
Frequency  of  SPO-initiated  Communication 
Frequency  of  User-initiated  Communication 
Frequency  of  Face-to-face  Meetings 
Frequency  of  User  Expressing  Dissatisfaction 
Method  of  Day-to-day  Communication 
Method  of  Communicating  Requirements 
Formal/ Informal  Communication  Channels 
Number  Initiated  by  SPO  of: 

Informal  Requirement  Changes 
Formal  Requirement  Changes 
Number  Initiated  by  User  of: 

Informal  Requirement  Changes 
Formal  Requirement  Changes 
Percentage  of  Time  Higher  Headquarters 
are  Involved  in  Communications 

On  the  survey  instrument  itself,  the  overall  order  of 

presentation  of  questions  was: 

Programmatic  Data 
Communications  Data 
Demographic  Data 

The  demographic  data  was  presented  last  so  that  the 
respondent  was  as  fresh  as  possible  when  answering  the 
programmatic  and  communications  related  questions.  Questions 
within  the  communications  section  were  arranged  so  as  to 
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maximize  internal  validity,  for  the  instrument.  Questions 
related  to  how  often  an  activity  occurs  asked  respondents  to 
reply  on  a  five  point  Likert-type  scale,  as  in  the  following 
sample  question  from  the  survey. 

How  often  does  the  user  initiate  communication  with  you? 

A.  Never 

B.  Rarely 

C.  Sometimes 

D.  Almost  Always 

E.  Always 

All  questions,  except  those  pertaining  to  demographic  data, 
were  answered  using  five  point  scales  similar  to  that  above. 
All  questions  included  were  designed  to  provide  information 
on  which  factors  in  the  SPO/User  communication  process  are 
related  to  the  successful  implementation  of  program 
requirements. 

In  draft  form  the  survey  instrument  was  administered  to 
a  group  of  relatively  experienced  program/project  managers. 
These  managers  were  students  in  an  AFIT  Systems  400  course, 
which  is  designed  to  provide  exposure  to  advanced  topics  in 
acquisition  management  to  staff  level  program  managers.  The 
survey  was  tested  in  this  environment  to  help  ensure  that 
questions  were  not  ambiguous,  and  that  no  significant 
variables  were  left  out. 

As  a  result  of  the  feedback  received  from  the  pilot 
study,  the  survey  was  changed  in  several  ways.  The  original 
survey  instrument  for  the  pilot  study  used  a  percentage- 


based  scale  for  responses  concerning  event  frequencies. 

Many  comments  from  participants  showed  that  this  scale  was 
difficult  to  interpret.  This  led  to  changing  the  response 
scale  to  the  one  described  above.  Many  participants  also 
expressed  confusion  as  to  the  precise  definition  of  user, 
requirement  change,  and  contract  change.  As  a  result, 
definitions  of  these  terms  were  included  in  the  instructions 
accompanying  the  survey.  The  question  in  the  pilot  survey 
concerning  the  current  phase  of  the  program  did  not  include 
a  response  category  for  a  post-production  or  modificaton 
phase.  Several  respondents  indicated  that  such  a  category 
was  needed,  so  it  was  added. 

The  pilot  study  was  delivered  to  50  people,  and  35 
responded,  yielding  a  response  rate  of  70  percent.  Of  those 
responding,  61  percent  were  majors  and  39  percent  were 
lieutenant  colonels.  Since  the  sample  size  was  small,  and 
since  only  a  narrow  section  of  relatively  experienced 
personnel  participated,  the  pilot  study  was  used  only  to 
clarify  and  improve  the  survey  instrument.  No  meaningful, 
externally  valid  analysis  could  be  performed  with  the 
limited  responses  available. 

Population/ As  sumptions 

The  population  of  interest  is  all  acquisition  management 
personnel,  with  a  duty  Air  Force  Specialty  Code  (AFSC)  of 
27XX,  who  are  active  duty  officers,  grades  02  though  05,  and 
are  currently  stationed  within  the  continental  United  States 


(CONUS).  The  ATLAS  Database  indicated  that  there  were  1524 
officers  with  fully  qualified  27XX  AFSC's.  These  could  be 
divided  into  two  groups  of  interest.  878  officers  with  a 
2724  AFSC ,  and  646  officers  with  a  2716  AFSC. 

Sample  Selection/Size.  Based  on  the  information  from 
the  ATLAS  Database,  and  the  fact  that  it  is  desirable  to  use 
a  stratified  random  sample  to  ensure  that  the  data  collected 
represents  the  full  range  of  acquisition  management 
experience,  the  following  method  was  used.  The  desired 
sample  sizes  were  calculated  using  the  HQ  USAF/ACM  sample 
size  formula  (4:11-14). 

N(z^)  *  p(l-p) 

n  - - 

C(N-l)  *  (d2)]  +  C  ( z2)  *  p(l-p)] 

where:  n  *  sample  size 

N  =  population  size 
p  =  maximum  sample  size  factor  (.5) 
d  =  desired  tolerance  (.05) 
z  =  factor  of  assurance  for  95% 
confidence  level  (1.96) 

This  formula  can  be  used  when  the  population  sizes  are 
known,  and  a  conf idence/reliability  level  of  95%  +  5%  is 
desired.  After  the  initial  sample  sizes,  267  for  2724  and 
241  for  2716,  were  obtained  from  the  above  equation,  they 
were  multiplied  by  1.43,  in  anticipation  of  a  70%  survey 
return  rate.  For  the  strata,  sample  sizes  of  381  (2724)  and 
344  (2716)  resulted. 

Using  these  numbers,  a  request  for  a  listing  of  725 
names,  to  be  randomly  selected  from  within  the  strata,  was 


submitted  to  the  ATLAS  Database.  A  list  of  724  names 


resulted,  and  724  surveys  were  mailed. 

A  convenience  sample  of  17  personnel  working  with  the 
using  command  Systems  Offices  at  ASD  were  contacted  to 
participate  in  an  interview  questionnaire. 

Analysis 

The  key  dependent  (response)  variable  analyzed  was  the 
effective  communication  of  the  users'  system  requirements  to 
the  SPO.  This  was  operationally  defined  in  terms  of  the 
frequency  of  the  users  voicing  dissatisfaction  to  the  SPO 
about  problems  with  system  requirements  implementation,  as 
reported  by  acquisition  management  personnel  working  in 
SPO's.  The  statistical  analysis  technique  which  is  most 
suited  to  evaluating  relationships  between  the  response 
variable  and  the  other  variables  is  discriminant  categorical 
data  analysis.  This  is  true  since  the  level  of  data  will  be 
primarily  nominal  and  ordinal.  Descriptive  statistics 
concerning  the  data  were  also  calculated. 

Computation  Method.  The  SAS  statistical  analysis 
package  running  on  a  Digital  Equipment  Corporation  VAX 
11/780  computer  system  at  AFIT  (the  Classroom  Support 
Computer)  was  used  to  perform  all  calculations.  Two 
procedures  within  the  SAS  package  were  used:  Proc  Means, 
and  Proc  Freq.  Proc  means  was  used  to  calculate  all 
descriptive  statistics.  Proc  Freq  was  used  to  generate  the 
two-way  contingency  tables  used  in  the  categorical  data 


analysis.  Proc  Freq  also  calculated  chi-square  values  where 
appropriate,  to  help  identify  any  relationships  between  the 
response  variable  and  other  variables.  The  chi-square 
independence  test  for  this  categorical  analysis  of  the 
response  variable  and  appropriate  selected  variables  was 
conducted  with  the  null  hypothesis  that  there  is  no 
relationship,  represented  by: 

H0:  pii  =  Pi.  *  Pa  where:  pi.3  is  the  probability  of  a 

a  randomly  selected  indi¬ 
vidual  being  in  both  a  par¬ 
ticular  row  and  column  of 
the  contingency. 

And  the  alternate  hypothesis  is  that  there  is  a  relationship 
between  the  response  variable  and  the  other  selected 
variables: 

H^:  H„  is  not  true. 

These  tests  will  be  conducted  at  the  .05  significance  level. 

From  a  practical  standpoint,  the  results  of  these 
statistical  tests  should  provide  some  insight  into  which 
factors  in  the  requirements  communication  process  are  the 
most  important.  Based  on  this  analysis  some  recommendations 
for  further  research  were  made. 
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IV.  Results  and  Discussion 


Introduction 


This  chapter  presents  the  demographic  data  collected, 
and  the  results  of  the  statistical  analyses  performed,  along 
with  other  results  deemed  suitable  for  presentation  and 
review.  The  demographic  data  are  presented  first,  and  then 
the  results  are  presented  for  each  investigative  question, 
beginning  with  Question  1.  Other  pertinent  findings  are 
presented  last. 


General  Information 

This  section  provides  general  information  about  the  data 
collection  and  response  level,  and  gives  summaries  of 
pertinent  demographic  data. 

Data  Collection.  Of  the  724  surveys  that  were  sent  out, 
385  were  returned  for  an  overall  response  rate  of  53  per¬ 
cent.  93  of  the  385  respondents  indicated,  on  survey  ques¬ 
tion  1,  that  they  were  not  in  system  acquisition,  leaving 
292  responses  usable  for  the  analysis  conducted.  This 
resulted  in  a  usable  response  rate  of  40  percent.  The 
number  of  surveys  available  for  analysis  resulted  in  an 
actual  confidence  interval  somewhat  less  than  the  95+5 
percent,  as  presented  in  Chapter  III.  However,  since  the 
surveys  which  were  returned,  but  not  used,  were  from  27XX's 
not  currently  working  in  areas  directly  related  to  system 
acquisition,  the  population  of  interest,  presented  in 
Chapter  III.  ,  can  be  reduced  in  size.  It  is  also  reasonable 
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to  assume  that  of  the  47  percent  who  did  not  respond  there 
were  some  number  who  also  were  not  currently  involved  in 


areas  directly  related  to  systems  acquisition.  This  would 
further  reduce  the  baseline  population  of  interest. 
Therefore,  based  on  292  usable  responses  and  the  above 
discussion,  the  results  are  presented  with  an  approximate 
confidence  interval  of  90  +  5  percent. 

Demographics.  The  data  collected  are  shown  by  the 
tables  below  to  be  representative  of  a  wide  cross  section  of 
the  27XX  career  field.  The  data  shown  below  were  collected 
as  responses  to  survey  questions  40,  1-3,  6,  8,  41-44,  46- 
47,  49,  and  50,  respectively. 


Table  1 

Product  Division  Involved 


CUMULATIVE 

CUMULATIVE 

PRODDIV 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

ASD 

141 

49.0 

141 

49.  0 

ESD 

29 

10.  1 

170 

59.  0 

SD 

31 

10.  8 

201 

69.  8 

AD 

21 

7.  3 

222 

77.  1 

HSD 

5 

1.  7 

227 

78.  8 

BMO 

17 

5.  9 

244 

84.  7 

Other 

44 

15.  3 

288 

100.  0 

Table  1  shows  that,  as  expected,  the  largest  percentage  of 
respondents  (49  percent)  were  members  of  ASD,  but  every 
product  division  was  represented.  The  majority  of  those 
personnel  responding  in  the  "Other"  category  were  currently 


working  on  a  joint  service  program  or  as  a  program  manager 


for  a  test  facility.  Respondents  were  approximately  evenly 
split  between  single  system  SPO's  and  basket,  or  multi¬ 
program,  SPO's,  with  118  working  in  single  system  SPO's,  and 
132  in  basket  SPO's. 


Table  2 

Type  of  SPO  or  Job 


SPOTYP 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

Single  Sys 

SPO 

118 

40.  5 

118 

40.  5 

Basket 

SPO 

132 

45.  4 

250 

85.  9 

Work  as  SYSTO 

21 

7.  2 

271 

93.  1 

Work  as 

PEM 

20 

6.  9 

291 

100.  0 

Table  3 


Phase 

of  Program 

PHASE 

FREQUENCY 

CUMULATIVE 
PERCENT  FREQUENCY 

CUMULATIVE 

PERCENT 

Concept  Exp  Phase 

7 

2.  4 

7 

2.  4 

Dem/Val  Phase 

28 

9.  7 

35 

12.  2 

FSD  Phase 

74 

25.  7 

109 

37.8 

Production  Phase 

55 

19.  1 

164 

56.  9 

Post  Prod/Mod 

10 

3.  5 

174 

60.  4 

Concept/ Dem/Val 

15 

5.  2 

189 

65.  6 

Dem/Val/ FSD/ Prd 

38 

13.  2 

227 

78.  8 

Prod/Post  Prod 

19 

6.  6 

246 

85.  4 

Early  4  Late  Phas 

42 

14.  6 

288 

100.  0 

The  good  distribution  of  respondents  between  single  system 
and  basket  SPO's,  shown  in  Table  2,  allowed  a  comparison  to 
be  made  between  the  two  environments  to  determine  if  any 
possible  difference  existed  in  communication  techniques  or 
their  perceived  success  fulness .  This  comparison  will  be 
presented  in  a  later  section. 

The  respondents  were  involved  in  programs  which 
represented  the  entire  range  of  the  systems  acquisition 
process,  as  shown  in  Table  3.  The  largest  group  of 
respondents  (44.8  percent)  were  involved  with  either  full- 
scale  development  or  production  programs.  More  than 
expected  (39.6  percent)  were  involved  either  in  several 
programs,  each  of  which  was  in  a  different  phase,  or  in  a 
single  program  of  concurrent  nature,  that  is,  a  program 
which  is  compressed  so  that  it  is  in  two  or  more  phases 
simultaneously  (see  Table  3). 

Table  4 


Total 

Program 

Cost 

CUMULATIVE 

CUMULATIVE 

COST 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

Less  than  $100K 

1 

0.  3 

1 

0.  3 

100K  -  999K 

7 

2.  4 

8 

2.  8 

1M  -  29. 9M 

44 

15.  2 

52 

18.  0 

30M  -  99. 9M 

43 

14.  9 

95 

32.  9 

100M  or  more 

194 

67.  1 

289 

100.  0 

Table  4  shows  that  the  majority  (67  percent)  of  programs 


which  respondents  are  working  involve  more  than  $100 
million.  Fully  82  percent  of  the  programs  involve  greater 
than  $30M. 

Table  5  shows  that  the  largest  (26.4  percent)  group  of 
respondents  work  programs  which  will  support  users  from  more 
than  one  command.  Those  respondents  reporting  "Some  Other 
User”  usually  stated  that  their  users  were  DoD  or  national 
agencies,  or  were  classified.  The  50  respondents  not 
answering  this  question  reported  that  they  support  overseas 
users . 

As  expected,  Table  6,  shows  that  the  majority  of  users 
are  field  units,  with  only  22  percent  representing  head¬ 
quarters. 


Table  5 

Command  of  the  User 


CUMULATIVE  CUMULATIVE 


USERCMD 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

User  is  SAC 

56 

23.  1 

56 

23.  1 

User  is  TAG 

62 

25.  6 

118 

48.  8 

User  is  MAC 

14 

5.  8 

132 

54.  5 

User  is  ESC 

3 

1.  2 

135 

55.  8 

User  is  ATC 

3 

1.  2 

138 

57.  0 

User  is  AFCC 

1 

0.  4 

139 

57.  4 

User  is  AFLC 

2 

0.  8 

141 

58.  3 

User  is  AFSC 

11 

4.  5 

152 

62.  8 

Some  Other  User 

26 

10.  7 

178 

73.  6 

Mutiple  Users 

64 

26.  4 

242 

100.  0 

Table  6 


Field  or  Headquarters  User 


CUMULATIVE  CUMULATIVE 


USERTYP 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

User  is  HQ 

62 

22.  2 

62 

22.  2 

Field  Unit 

168 

60.  2 

230 

82.  4 

Other 

34 

12.  2 

264 

94.  6 

i  and  Field 

15 

5.  4 

279 

100.  0 

The  rank  of  the  respondents  was  fairly  evenly  spread 
(see  Table  7).  This  is  as  was  expected,  since  the  sample 
was  drawn  from  2724's,  0-2  through  0-4,  and  2716’s,  0-4  and 
0-5.  It  is  not  known  how  the  survey  reached  the  second 
lieutenants  who  responded,  but  the  colonels  wrote  comments 
to  the  effect  that  they  were  either  recently  promoted  or  had 
a  line  number  to  colonel. 


Table  7 

Rank  of  Respondent 


RANK 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

2LT 

3 

1.  0 

3 

1.  0 

1LT 

82 

28.  4 

85 

29.  4 

CAPT 

77 

26.  6 

162 

56.  1 

MAJ 

54 

18.  7 

216 

74.  7 

LTCOL 

71 

24.6 

287 

99.  3 

COL 

2 

0.  7 

289 

100.  0 
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Table  8 

Type  of  Degree  held 


DEGREE 


CUMULATIVE 

FREQUENCY  PERCENT  FREQUENCY 


Bachelor  * s 
Master  *  s 
Doctoral 


43.  1 
56.  2 
0.  7 


CUMULATIVE 

PERCENT 

1 


100.  0 


There  was  an  approximately  even  split  between  those 
respondents  who  had  bachelor's  degrees  and  those  who  had 
Master's  degrees  (see  Table  8). 

Approximately  70  percent  of  the  respondents  had  at  least 
one  degree  which  was  in  an  engineering  or  technical  field. 
Table  9  shows  that  only  19.6  percent  of  those  responding  had 
a  non-technical  degree.  34. 7  percent  responded  that  they 
had  degrees  in  more  than  one  discipline,  with  the  most 
frequent  combination  being  a  technical  undergraduate  degree 
and  a  graduate  degree  in  a  management-related  field. 

Table  9 

Area  of  Specialization 


100.  0 


Table  10 


Type  of  Position  by  Title 


CUMULATIVE  CUMULATIVE 

TITLE  FREQUENCY  PERCENT  FREQUENCY  PERCENT 


SPO  Director 

3 

Pgm  Mgr 

68 

Prj  Mgr 

74 

SYSTO 

18 

PEM 

18 

Dep  SPO  Dir 

3 

Mgr  Of  Prj  Mgrs 

31 

Config/Data  Mgr 

2 

Proj  Engr 

4 

Test  Mgr 

22 

Other 

47 

1.  0 

3 

1.  0 

23.  4 

71 

24.  5 

25.  5 

145 

50.  0 

6.  2 

163 

56.  2 

6.  2 

181 

62.  4 

1.  0 

184 

63.  4 

10.  7 

215 

74.  1 

0.  7 

217 

74.  8 

1.  4 

221 

76.  2 

7.  6 

243 

83.  8 

16.  2 

290 

100. 0 

Table  10  shows  that  61. 3  percent  of  the  respondents  are 
directly  involved  in  program  management  either  as  program 
managers,  or  as  SPO  directors.  The  majority  of  those 
responding  in  the  ’'Other"  category  stated  that  they  were 
involved  in  the  cost/financial  management  area.  Those  who 
were  not  directly  involved  in  program  management,  but  did 
respond  to  the  survey,  indicated  that  they  did  communicate 
with  the  users  concerning  requirements,  and,  therefore,  they 
were  included  in  the  analysis. 

The  majority  (60.2  percent)  of  those  responding  had  less 
than  four  years  experience  in  program  management  (see  Table 
11)  . 

62. 2  percent  of  respondents  have  had  no  operational 
experience  during  their  careers.  Table  12  shows  that  37.8 
percent  have  had  at  least  one  operational  tour.  14. 8 


Table  11 


Years  Experience  in  Program  Management 


EXP 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

-  1  yr. 

26 

9.  5 

26 

9.  5 

1-2 

67 

24.  5 

93 

33.  9 

3-4 

72 

26.  3 

165 

60.  2 

5-10 

84 

30.  7 

249 

90.  9 

>  10 

25 

9.  1 

274 

100.  0 

percent  of  those  stating  that  they  had  operational 
experience  said  that  they  were  rated.  The  remaining 
operational  experience  was  in  missile  operations, 
maintenance,  space  operations  and  other  operational 
assignments. 

Professional  military  educational  (PME)  levels  ranged 
from  none  (11  percent,  Table  13)  to  all  (3.1  percent,  or 
nine  respondents) .  "All”  PME  included  SOS,  ACSC,  AWC,  and 
ICAF.  The  most  frequently  mentioned  "other”  PME  course 
which  was  mentioned  was  Marine  Command  and  Staff  College. 

Table  12 

Summary  of  Operational  Exp 


CUMULATIVE 

CUMULATIVE 

EXPSUM 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

OPER 

110 

37.  8 

110 

37.  8 

NON-OPS 

181 

62.  2 

291 

100.  0 

Table  13 


PME  Summary 


CUMULATIVE 

CUMULATIVE 

PME 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

SOS  ONLY 

119 

40.  9 

119 

40. 9 

ACSC  ONLY 

3 

1.  0 

122 

41.  9 

AWC  ONLY 

1 

0.  3 

123 

42.  3 

SOS  «  ACSC 

66 

22.  7 

189 

64.  9 

SOS  4  AWC 

1 

0.  3 

190 

65.  3 

SOS  4  ICAF 

4 

1.  4 

194 

66.  7 

SOS,  ACSC,  AWC 

28 

9.  6 

222 

76.  3 

ALL 

9 

3.  1 

231 

79.  4 

OTHER 

28 

9.  6 

259 

89.  0 

NONE 

32 

11.  0 

291 

100.  0 

Table  14 

Acquisition  Educ  Summary 

CUMULATIVE 

CUMULATIVE 

SCHOOL 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

SYS100  ONLY 

19 

6.  5 

19 

6.  5 

SYS200  ONLY 

11 

3.  8 

30 

10.  3 

SYS400  ONLY 

11 

3.  8 

41 

14.  0 

DSMC  ONLY 

41 

14.  0 

82 

28.  1 

SYS100  &  SYS200 

95 

32.  5 

177 

60.  6 

ALL  SYS 

20 

6.  8 

197 

67.  5 

SYS  a  SAS 

1 

0.  3 

198 

67.  8 

SYS  a  DSMC 

4 

1.  4 

202 

69.  2 

SAS  a  DSMC 

1 

0.  3 

203 

69.  5 

NONE 

22 

7.  5 

225 

77.  1 

SAS  ONLY 

11 

3.  8 

236 

80.  8 

MULTI 

56 

19.  2 

292 

100.0 

Professional 

continuing 

education 

related  to 

acquisition 

management  also  ranged  from  none  (7.5  percent,  Table  14)  to 
AFIT  Systems  100,  200,  and  400  <6.8  percent)  to  some  AFIT 


courses  and  DSMC  (1.4  percent).  As  expected,  the  largest 
respondent  group  stated  that  they  had  completed  AFIT  Systems 
100  and  200,  or  equivalent  courses  such  as  the  introductory 
course  at  Systems  Acquisition  School  (SAS),  at  Brooks  AFB. 

Investigative  Question  Results 

This  section  presents  the  data  and  analysis  relevant  to 
each  investigative  question,  beginning  with  question  1. 

Question  1.  Investigative  Question  1  was  "How  are  most 
of  the  communications  between  the  SPO  and  user  conducted, 
e. g. ,  by  message,  phone,  etc.?"  This  question  was  answered 
through  the  responses  to  questions  10  through  12  and  14  of 
the  survey.  A  comparison  of  tables  15  -  17,  which  show  the 
method  and  frequency  of  communication  relative  to  the  SPO, 
shows  that  the  large  majority  of  communications  with  the 
user  was  conducted  by  phone,  as  expected.  Also,  Table  18 
shows  that  the  most  often  used  method  for  user-initiated 
communication  was  the  phone.  However,  there  was  a 
statistically  significant  difference  in  the  relative  amount 
each  method  was  used  based  on  the  location  of  the  user 
(Conus  or  OConus) .  This  difference  was  detected  using  a 
chi-square  test  of  independence,  as  described  in  Chapter 
III,  which  applies  to  all  further  tests  described  in  this 
chapter.  When  comparing  user- initiated  communication 
(COMTYP)  with  location  of  the  user  (USERLOC)  in  a  two-way 
contingency  table,  the  chi-square  value  was  29. 6  with  a  prob 
value  of  0.0,  which  indicates  a  high  level  of  dependence. 


The  data  indicated  that  split  between  phone,  message,  and 
face-to-face  meeting  for  users  located  Conus  was  75  -  15  - 
10  percent,  respectively.  For  users  located  overseas,  the 
split  was  51-45-4  percent. 


Table  15 

Frequency  of  Communication  by  Phone 


PHO 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

Never 

10 

3.  4 

10 

3.  4 

Rarely 

23 

7.  9 

33 

11.  4 

Sometimes 

80 

27.  6 

113 

39.  0 

Almost  Always 

171 

59.  0 

284 

97.  9 

Always 

6 

2.  1 

290 

100.  0 

Table  16 

Frequency  of  Communication  by  Message 


MES 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

Never 

16 

5.  5 

16 

5.  5 

Rarely 

47 

16.  2 

63 

21.  6 

Sometimes 

184 

63.  2 

247 

84.  9 

Almost  Always 

43 

14.  8 

290 

99.  7 

Always 

1 

0.  3 

291 

100.  0 

The  user  representatives,  interviewed  at  ASD,  indicated 
that  they  communicated  with  SPO  personnel  mostly  by  face-to- 
face  meetings.  They  stated  that  they  communicated  with 


Table  17 


Frequency  of  Communication  by  Meeting 


CUMULATIVE 

CUMULATIVE 

MEET 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

Never 

8 

2.  7 

8 

2.  7 

Rarely 

50 

17.  2 

58 

19.  9 

Sometimes 

208 

71.  5 

266 

91.  4 

Almost  Always 

23 

7.  9 

289 

99.  3 

Always 

2 

0.  7 

291 

100. 0 

User 

Table  18 

Communicates  Most 

Frequently  By 

CUMULATIVE 

CUMULATIVE 

COMTYP 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

By  Phone 

192 

66.  9 

192 

66.  9 

By  Message 

59 

20. 6 

251 

87.  5 

By  Meeting 

24 

8.  4 

275 

95.  8 

Other  Method 

4 

1.  4 

279 

97.  2 

Multi-Method 

8 

2.  8 

287 

100.  0 

their  counterparts  in  the  field  or  at  their  respective 
headquarters  mostly  by  phone. 

Overall,  the  data  showed  that  the  largest  portion  of 
communications  between  SPO  and  user  was  conducted  by  phone, 
regardless  of  user  location.  However,  for  users  located 
overseas,  a  much  larger  percentage  of  communication  were 
conducted  by  message  than  for  those  located  within  the 


Conus 


Question  2.  Investigative  Question  2  was  "How  frequent¬ 
ly  do  the  SPO  and  user  communicate?”  This  question  was 
answered  through  responses  to  survey  questions  9  and  13. 
Table  19  shows  that  52. 4  percent  of  the  respondents  said 
that  they  communicated  with  the  user  more  than  six  times  per 
month.  Unexpectedly,  13. 4  percent  said  that  they  communi¬ 
cated  with  the  user  less  than  once  a  month,  and  2. 4  percent 
said  they  never  communicate  with  the  user. 


Table  19 

Frequency  of  SPO-Initiated  Communication 


COMFREQ 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

Never 

7 

2.  4 

7 

2.  4 

<  Once  a  Month 

39 

13.  4 

46 

15.  9 

1-5  Times/Mo. 

92 

31.  7 

138 

47.  6 

10  Times  a  Mo. 

55 

19.  0 

193 

66.  6 

10  Times  a  Mo. 

97 

33.  4 

290 

100. 0 

When  asked  how  often  the  users  initiated  communications  with 
the  SPO,  more  than  20  percent  of  the  respondents  indicated 
that  their  users  rarely  or  never  initiated  communication. 
Fewer  than  eight  percent  said  that  their  users  always  or 
almost  always  initiated  communication. 

All  of  the  user  representatives  indicated  that  they 


communicated  with  the  SPO  on  a  daily  basis,  and  the  majority 
stated  that  they  communicated  with  their  headquarters  or 
field  units  at  least  weekly. 


Question  3.  Investigative  Question  3  was  ”Do  most 
communications  follow  formal  or  informal  command  channels?” 
This  question  was  answered  with  responses  from  survey 
question  27.  Additional  information  was  provided  by 
responses  to  questions  17  through  21. 

Table  20 


Informal 

Channels  Are 

Used 

CUMULATIVE 

CUMULATIVE 

INFOCOM 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

Never 

4 

1.  4 

4 

1.  4 

Rarely 

19 

6.  8 

23 

8.  2 

Sometimes 

83 

29.  7 

106 

38.  0 

Almost  Always 

138 

49.  5 

244 

87.  5 

Always 

35 

12.  5 

279 

100.  0 

62  percent  of  the  respondents  indicated  that  require¬ 
ments  problems,  voiced  by  the  user,  always  or  axmost  always 
surfaced  through  informal  channels  prior  to  being  passed 
along  the  formal  chain  of  command.  Only  1. 4  percent  stated 
that  informal  channels  were  never  used. 

Not  surprisingly,  the  user  representatives  working  with 
the  SPO’s  at  ASD  said  that  they  almost  always  used  informal 
channels  to  discuss  problems.  They  felt  strongly  that 
informal  channels  wer^  a  key  part  of  successfully  resolving 
requirements  problems. 

Questions  17  through  21  dealt  with  the  frequencies  that 
the  SPO’s  and  users  included  their  respective  headquarters 


and  each  other's  headquarters  on  official  message  traffic. 
27. 5  percent  of  the  respondents  indicated  that  they  always 
addressed  the  user's  headquarters,  compared  with  only  10.6 
percent  of  the  respondents  indicating  that  the  users  always 
addressed  the  SPO's  headquarters.  This  may  indicate  more 
willingness  on  the  part  of  the  user  to  exercise  less  formal 
channels,  or  it  may  be  a  result  of  formal  direction  to  the 
SPOs  to  include  all  headquarters  on  their  message  traffic. 

Question  4.  Investigative  Question  4  was  ’’Does  SPO 
and/or  user  acquisition  experience  contribute  to  better 
communication?”  This  question  was  answered  by  comparing 
questions  16,  22  and  37  to  question  46.  Questions  16  and  22 
deal  with  the  frequency  that  the  user  expresses 
dissatis faction  with  some  aspect  of  requirements 
implementation.  Question  37  is  an  evaluation,  by  the 
respondents,  of  the  overall  adequacy  of  SPO-to-user 
communication,  for  their  program.  Question  46  asked  how 
much  experience  the  respondent  had  in  program  management 
(see  Table  21).  Since  a  large  sample  of  user 
representatives  was  not  used,  only  the  attitudes  and 
perceptions  of  the  user  representatives  concerning 
need/applicability  for  acquisition  experience  on  the  part  of 
the  user  are  presented.  No  statistical  analysis  will  be 
performed  on  the  effects  of  user  acquisition  experience. 

Table  21  shows  that  the  largest  respondent  group  (30.7 
percent)  had  between  five  and  ten  years  of  experience.  when 
the  values  in  Table  21  were  cross  tabulated  with  the  two 


questions  measuring  frequency  of  communication  regarding 
dissatisfaction,  no  statistically  significant  dependence  was 
found  between  the  experience  level  of  the  program  manager, 
and  the  frequency  of  communication  regarding 
dissatisfaction.  The  user  representatives  felt  that 
acquisition  experience  on  the  part  of  the  program  manager 
was  important,  but  that  it  was  less  important  for  users. 

They  felt  that  after  the  initial  shock  of  beginning  to  work 
with  the  environment  of  the  SPO,  there  was  not  a  great  need 
for  further  experience.  The  user  representatives  felt  that 
once  the  language  of  acquisition  was  learned,  and  the 
general  systems  acquisition  process  became  familiar,  actual 
formal  experience  was  less  valuable. 


Table  21 

Years  Experience  in  Program  Management 


EXP 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

1/2  -  1  yr. 

26 

9.  5 

26 

9.  5 

1-2 

67 

24.  5 

93 

33.  9 

3-4 

72 

26.  3 

165 

60.  2 

5-10 

84 

30.  7 

249 

90.  9 

>  10 

25 

9.  1 

274 

100. 0 

Table  22  shows  that  there  is  no  statistically  significant 
relationship  between  program  managers'  acquisition 
experience  and  their  assessment  of  SPO/user  communications. 


1_**4  **>  mt*  .«>  *-■» 


Question  5^  Investigative  Question  5  was  "Does  having 
operational  experience  (or  the  lack  of  it)  effect  the 
program  manager's  ability  to  effectively  interpret  and 
implement  requirements?”  This  question  was  answered  using 
the  data  collected  with  survey  questions  16,  22  and  47. 
Questions  16  and  22  are  the  response  variables  as  described 

Table  22 

Program  Manager  Experience  By  Assessment  of  Comm 


EXP (Years  Experience) 

ASESMENT( Assessment  of  Communications ) 


FREQUENCY  | 


I  Very  II  II  Very  I 

I  Poor  |  Poor  |  Average  I  Good  I  Good  I  TOTAL 

+ - + - + - + - + - + 

I  21  41  61  11  I  3  I  26 

+ - + - + - + - + - + 


1/2  -  1  yr. 

-  + - 

1 

2 

1 

4 

-+ - 

1 

6 

1 

11 

1 

3 

04 

1 

H 

1 

1 

1 

4 

1 

19 

1 

23 

1 

18 

3-4 

1 

.  + - 

1 

1 

4 

1 

-  + - 

23 

1 

29 

1 

13 

5  -  10  I  II  61 

>  10  |  01  01 

TOTAL  5  18 

CHI-SQUARE  =  15. 455 


21  I  35  I  20  |  83 

7|  13  I  5  I  25 

76  111  59  269 

PROB  VALUE  =  0.492 


above  and  in  Chapter  III.  Question  47  asks  what  operational 
experience,  if  any,  the  respondent  has  had  (see  Table  12). 

Comparing  the  relationship  between  the  operational 
experience  of  respondents  to  the  frequency  with  which  their 
users  voice  dissatisfaction  yields  an  unexpected  result. 


The  crosstabulation  in  Table  23  shows  that  there  is  no 
significant  relationship  between  the  two  variables.  The 
same  was  true  when  comparing  the  responses  for  question  22, 
another  measure  of  the  frequency  which  user  voice 
dissatisfaction  to  the  SPO.  There  was  also  no  statistically 
significant  relationship  between  the  operational  experience 
of  program  managers  and  their  assessment  of  the 
communication  process.  The  response  cross tabulation  for 
these  two  variables  is  shown  in  Table  24. 

The  user  representatives  generally  felt  that  operational 
experience  on  the  part  of  program  office  personnel  was 
essential  if  the  communication  process  was  to  improve.  They 
felt  that  it  was  especially  important  for  the  project 
engineers  to  have  operational  experience. 

Table  23 

Respondents’  Operational  Exp  By  User  Dissatisfaction 


EXPSUM( Summary  of  Operational  Exp) 

DISAT( Frequency  User  expresses  Dissatisfaction) 

FREQUENCY  I 

I  I  I  Some-  I  Almost  I  I 

I  Never  I  Rarely  I  times  I  Always  I  Always  I  TOTAL 

OPER  I  51  42  I  52  I  7  |  2  I  108 

- + - + - + - + - + - + 

NON-OPS  I  91  65  I  84  I  18  I  0  I  176 

TOTAL  14  107  136  25  2  284 


CHI-SQUARE  =  4. 428 


PROB  VALUE 


0.  351 


Table  24 

Operational  Experience  By  SPO  Assessment  Of  Communication 


EXPSUM( Summary  of  Operational  Exp  of  Managers) 
ASESMENT( Assessment  of  Communications) 
FREQUENCY  I 


1 

Very 

1 

1 

1 

1 

Very  1 

1 

Poor 

1  Poor 

1 

Average  1 

Good 

1 

Good  1 

TOTAL 

- +  - 

— 

-  + - 

-  +  - 

- + 

— 

-  +  - 

- + 

OPER  1 

2 

1  6 

1 

34  I 

37 

1 

28  1 

10  7 

- +  . 

— 

-  + - 

-  +  - 

- +  -■ 

-  +  - 

- + 

NON-OPS  1 

4 

1  12 

1 

47  | 

83 

1 

33  1 

179 

— 

-  + - 

- + 

-  +  - 

TOTAL 

6 

18 

81 

120 

61 

2  io 

CHI-SQUARE  = 

4.  986 

PROB 

VALUE 

= 

0.  289 

The  lack  of  a  relationship  between  the  respondents ' 
operational  experience  and  the  frequency  with  which  their 
users  voice  dissatisfaction  may  indicate  that  operational 
experience  is  not  as  important  as  most  of  the  user 
representatives  state.  A  more  likely  explanation  is  that  the 
measures  of  dissatis f action  provided  by  survey  questions  io 
(variable  UDISSAT)  and  22  (variable  DISAT)  are  biased 
because  the  respondents  are  program  office  personnel.  This 
is  addressed  further  in  Chapter  v. 

Question  6_.  Investigative  Question  6  was  "Does  physical 
separation  of  the  SPO  and  the  user’s  main  operating  location 
interfere  with  communications?"  This  question  was  answered 
by  examining  responses  to  survey  questions  4  and  5,  and 
comparing  them  with  reported  user  dissatisfaction.  Tables 
25  and  26  summarize  user  locations,  and  Table  27  shows  a 

45 


crosstabulation  between  Conus/Oconus  user  location  and  the 


frequency  with  which  the  user  expressed  dissatisfaction. 
There  is  no  statistical  relationship  between  the  two.  This 
is  representative  of  the  results  of  crosstabulations  between 
all  dissatisfaction  measures  and  all  questions  regarding 


Table  25 

User  Located  ConUS  or  OConUS 


USERLOC 

FREQUENCY 

PERCENT 

CUMULATIVE 

FREQUENCY 

CUMULATIVE 

PERCENT 

Within  ConUS 

178 

61.  2 

178 

61.  2 

OConUS 

55 

18.  9 

233 

80.  1 

Both 

58 

19.  9 

291 

10  0.  0 

Table  26 

Location 

of  Conus 

User 

CUMULATIVE 

CUMULATIVE 

CONUS LOC 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

Same  Base 

13 

5.  5 

13 

5.  5 

Within  iOOOmi 

73 

31.1 

86 

36.  6 

More  than  IOOOmi 

111 

47.2 

197 

83.  8 

Near  and  Far 

38 

16.  2 

235 

100.  0 

user  location.  This  agrees  with  the  opinions  expressed  by 
the  user  representatives  interviewed.  The  majority  of  them 
stated  that  the  location  of  the  ultimate  user  did  not  impact 
the  communicaton  of  requirements. 


Table  27 


User  Location  By  Frequency  of  Dissatisfaction  Communication 


USERLOC< ConUS  or  OConUS) 

DISAT( Frequency  User  expresses  Dissatisfaction) 


FREQUENCY 

1 

1 

1  Never 

1 

■  1  Rarely 

1 

1 

Some¬ 

times 

1 

1 

Almost 

Always 

1 

1 

Always 

1 

1 

TOTAL 

Within  ConUS 1 

9 

1 

66 

1 

82 

1 

16 

1 

1 

1 

174 

OConUS 

1 

1 

1 

16 

1 

32 

1 

3 

1 

1 

1 

53 

Both 

1 

4 

1 

25 

1 

22 

1 

6 

1 

0 

1 

57 

TOTAL 

14 

107 

136 

25 

2 

284 

CHI-SQUARE  =  7.98  PROB  VALUE  =  0.436 


Question  7.  Investigative  Question  7  was  ”Do  travel 
constraints  such  as  limited  TDY  funding  interfere  with 
communications?"  This  question  was  answered  with  data  from 
survey  question  36.  Question  36  asked  if  the  unavailability 
of  TDY  funds  adversely  affected  the  communication  of 
requirements.  68. 2  percent  of  the  respondents  answered  that 
lack  of  TDY  funds  either  rarely  or  never  hindered  the 
requirements  communications  process  (Table  28) .  The  user 
representatives,  however,  were  divided  on  this  issue,  with 
about  half  of  those  with  an  opinion  saying  that  TDY  funding 
had  no  effect  and  the  other  half  stating  that  more  TDY  funds 
for  both  users  and  SPO’s  would  enhance  communications. 


Table  28 


Effect  of  TDY  Funds  on  Communications 


CUMULATIVE 

CUMULATIVE 

TDYFUND 

FREQUENCY 

PERCENT 

FREQUENCY 

PERCENT 

Never 

110 

38.  5 

110 

38.  5 

Rarely 

85 

29.  7 

195 

68.  2 

Sometimes 

71 

24.  8 

266 

93.  0 

Almost  Always 

19 

6.  6 

285 

99.  7 

Always 

1 

0.  3 

286 

100. 0 

Other  Findings 

In  addition  to  the  analysis  performed  to  answer  the 
stated  investigative  questions,  the  data  were  analyzed  to 
see  if  any  other  statistically  significant  relationships 
existed  between  any  of  the  other  variables.  The  additional 
analyses  yielded  interesting  results  in  the  following  areas. 

-  Single  System  versus  Basket  SPO's 

-  User  initiated  communications 

-  The  number  of  requirements  changes  in  the  past  year 

-  The  respondents '  perceived  need  for  a  user 
representative 

-  Acquisition  training 

The  additional  results  are  presented  in  the  order  listed 
above. 

SPO  Type.  The  variable  which  identified  *he  type  of  SPO 
the  respondent  was  from  (SPOTYP)  was  compared  against  the 
remaining  dependent  variables,  and  the  following  statis¬ 
tically  significant  relationships  were  identified. 


First,  the  data  indicate  that  respondents  who  work  in 
basket  SPO’s  tend  to  communicate  more  frequently  by  phone 


than  those  who  work  in  single  system  SPO's  (Table  29). 
Another  statistically  significant  relationship  which  may 
help  to  explain  why  basket  SPO’s  communicate  with  the  user 
more  by  phone  is  the  relationship  between  type  of  SPO  and 
whether  or  not  a  user  representative  is  permanently  assigned 
as  part  of  the  SPO  team.  This  crosstabulation  is  shown  in 

Table  29 

Type  of  SPO  by  Phone  Communication  Frequency 


SPO(Single  System  or  Basket  SPO) 

PHO(Comm  percentage  by  Phone) 


FREQUENCY 


I  Some-  I  Almost  I 


1  Never  1  Rarely 

1 

times 

1  Always  1 

Always 

1  TOTAL 

Single  Sys 

SPOI  4  |  8 

1 

44 

1  58  | 

2 

1  116 

Basket 

SPO  |6|  13 

1 

28 

1  83  I 

2 

1  132 

TOTAL 

10  21 

72 

141 

4 

248 

CHI-SQUARE  =  8.582  PROB  VALUE  =  0.072 


Table  30,  which  demonstrates  that  there  is  a  strong  rela¬ 
tionship.  Single  system  SPO’s  are  much  more  likely  to  have 
a  user  representative  permanently  assigned  to  them  than  are 
basket  SPO's.  This  makes  sense,  because  the  dollar  value 
associated  with  a  single  system  SPO's  program  tends  to  be 
higher;  and,  therefore,  the  program  is  viewed  as  more 


important  to  the  user.  And  if  there  is  a  user  working  in 
the  building  with  a  respondent,  they  are  more  likely  to  talk 
face-to-face  than  over  the  phone. 


Table  30 

Type  of  SPO  by  User  Rep  in  SPO 


SPO( Single  System  or  Basket  SPO) 

USERREPfUser  Representative  in  SPO?) 


FREQUENCY 

1 

1 

Yes 

1 

No 

1 

TOTAL 

Single  Sys 

SPO  | 

89 

1 

28 

1 

117 

Basket 

SPO  | 

69 

I 

60 

1 

129 

TOTAL 

158 

88 

246 

CHI-SQUARE 

=  13.615 

PROB 

VALUE 

5S 

0.000 

Along  the  same  line  of  thought,  the  next  table  (Table  31) 
shows  just  the  opposite  relationship  for  face-to-face 
meetings.  Single  system  SPO's  are  more  likely  to  have 
meetings  than  are  basket  SPO’s. 

The  differences  between  single  system  SPO's  and  basket 
SPO’s  seemed  to  be  keyed  to  the  fact  that  single  system 
SPO’s  are  more  likely  to  have  a  user  representative 
assigned. 

User  Initiatied  Communication.  The  data  indicate  that 
there  is  a  strong  relationship  between  the  frequency  of  user 
initiated  communications  and  the  perceived  frequency  that 


Table  31 


Type  of  SPO  BY  Meeting 


SPO(Single  System  or  Basket  SPO) 

MEET (Comm  percentage  by  Meeting) 


FREQUENCY 


I  I  I  Some-  I  Almost  I  I 

I  Never  I  Rarely  I  times  I  Always  (Always  I  TOTAL 

-  + 

117 

-  + 

132 

-  + 

249 


Single  Sys 

- +  -- 

SPO) 

3  1 

18 

1 

79  | 

16 

-  + - 

1  1 

Basket 

SPO| 

4  I 

18 

! 

104  1 

5 

1  1 

TOTAL 

7 

36 

183 

21 

2 

CHI-SQUARE  = 

8.  447 

PROB  VALUE 

= 

0.  077 

user  communications  deal  with  some  aspect  of  dissatisfaction 
with  requirements  (Table  32).  This  is  logical  in  that  if 
the  users  are  satisfied  they  will  be  less  likey  to  call  the 
SPO,  than  if  they  disagree  with  the  way  requirements  inter¬ 
pretations  are  being  carried  out.  The  user  representatives 
added  credence  to  this  by  stating  that  if  there  is  some 
problem  in  requirements  implementation,  they  talk  to  the 
managers  and  project  engineers,  and  keep  talking  to  them 
until  the  problem  is  resolved.  As  expected,  when  things  are 
going  smoothly,  there  is  less  incentive  to  keep  up  with 
frequent  communications. 

Number  of  Requirements  Changes .  Corresponding  to  the 
above  observations  about  user  initiated  communication,  there 
is  a  relationship  between  the  number  of  requirements  changes 
on  a  program  and  the  overall  frequency  with  which  SPO/user 


communication  occurs.  Generally,  as  the  number  of  changes 


increase  the  communication  frequency  between  SPO  and  user 
also  tends  to  increase.  This  is  not  to  say  that  one  causes 
the  other,  only  that  they  are  related. 


Table  32 

Freq  of  User  Initiated  Communication  By 
Frequency  of  User  Comm  Dealing  with  Dissatisfaction 


USERINT(Freq  of  User  Initiated  Comm) 

UDISSAT(Comm  percentage  RE  Dissatisfaction) 

FREQUENCY  I 

I  I  I  Some-  I  Almost  I  I 

I  Never  I  Rarely  |  times  I  Always  I  Always  | TOTAL 


Never 

1 

1 

-  - 

1 

0 

-+-- 

1 

3 

1 

1 

+ - - 

1 

0 

-  + 

1 

5 

Rarely 

1 

6 

1 

22 

1 

22 

1 

3 

1 

2 

1 

55 

Sometimes 

1 

3 

1 

57 

1 

108 

1 

32 

1 

5 

1 

205 

Almost  Always 

1 

0 

1 

2 

1 

14 

1 

6 

1 

0 

1 

22 

Always 

1 

0 

1 

0 

1 

0 

1 

0 

1 

1 

1 

1 

TOTAL 

10 

81 

147 

42 

8 

288 

CHI-SQUARE 

= 

66. 

832 

PROB 

VALUE 

=  0 

.  000 

Perceived  Need  for  User  Representative.  An  interesting 
result  of  this  exploratory  analysis  was  that  respondents  who 
work  in  a  SPO  which  had  a  user  representative  were  much  more 
likely  to  say  that  having  a  user  representative  was 
beneficial  than  those  respondents  who  work  in  SPO's  without 
user  representation.  In  fact,  those  who  worked  in  SPO's 


without  permanently  assigned  user  representation  were  more 
likely  to  say  that  having  a  user  representative  would  not 
aid  in  the  communication  of  system  requirements  (see  Table 
33).  Not  unexpectedly,  all  of  the  users  representatives 
(who,  of  course,  are  currently  working  in  SPO's)  said  that 
it  was  very  important  to  have  direct  user  representation  at 
every  stage  of  the  acquisition  process. 

Table  33 

Perceived  Need  for  User  Rep  By 
User  Rep  in  SPO 


URNEED ( Need  for  User  Rep) 

USERREP(User  Representative  in  SPO?) 


FREQUENCY  I 

1 

Yes 

1 

No 

1 

TOTAL 

Yes  | 

23 

1 

52 

1 

75 

No  | 

7 

1 

62 

1 

69 

TOTAL 

30 

114 

144 

CHI-SQUARE  =  9.176  PROB  VALUE  =  0.002 


Acquisition  Training.  Several  interesting  relationships 
surfaced  in  the  area  of  what  type  of  acquisition  training, 
and  how  much  of  it,  respondents  had  received.  Out  of  all  of 
the  training  for  acquisition  personnel,  the  one  course  which 
is  related  to  the  factors  measured  in  this  research  is  AFIT 


Systems  100.  None  of  the  other  courses,  including  the 
introductory  course  at  System  Acquisition  School,  AFIT 


Systems  200,  AFIT  Systems  400,  and  DSMC,  seemed  to  be 
related  to  the  way  respondents  answered  any  of  the  other 
survey  questions,  except  rank  and  number  of  personnel 
supervised.  It  is  particularly  interesting  to  note  that  if 
respondents  had  completed  Systems  100,  they  were  much  more 
likely  to  state  that  a  user  representative  would  benefit  the 
communications  process,  than  if  they  had  not  had  the  course 
( see  Table  34)  . 


Table  34 

Completed  Systems  100  By 
Perceived  Need  for  User  Rep 


SYSONEC Systems  100) 

URNEED(Need  for  User  Rep) 


FREQUENCY  I 

1 

Yes  I 

No  I 

TOTAL 

Yes  1 

50  I 

26  | 

76 

No  1 

25  1 

43  1 

68 

TOTAL 

75 

69 

144 

CHI-SQUARE  =  12. 115 
PROB  VALUE  =  0.001 


Anotner  interesting  link  to  Systems  100,  that  is  also  not 
evident  for  any  of  the  other  acquisition  courses,  is  to  the 
respondents'  assessment  of  the  overall  SPO-to-user 
communication  process.  If  the  respondents  had  completed 
Systems  100,  they  were  much  more  likely  to  make  a  very 


positive  assessment  of  the  state  of  communications  than  if 
they  had  not  taken  the  course  (see  Table  35).  The  data  does 
not  indicate  that  the  actual  state  of  communications  was  any 
better  or  worse  for  the  two  categories  of  respondents,  but 
their  attitudes  are  certainly  different. 

As  was  briefly  mentioned  above  in  the  discussion  of 
investigative  question  4,  the  users  representatives  almost 
all  agree  that  some  acquisition  experience,  on  their  part 
would  be  beneficial.  The  same  is  true  of  their  responses 
concerning  acquisition  training.  Most  of  the  user 
representatives  feel  that  the  communication  of  requirements 
would  be  enhanced  if  they  received  some  acquisition  training 
(but  not  too  much). 

Table  35 

Completed  Systems  100  By  Assessment  of  Communications 


SYSONE( Systems  100) 

ASESMENT( Assessment  of  Communications) 

FREQUENCY  I 

I  Very  I  I  I  i  Very  I 


1 

Poor 

1 

Poor 

1 

_  ^  _ 

Average  1 

Good 

1 

i-  _ 

Good 

1 

TOTAL 

Yes  i 

4 

T 

1 

.X. 

6 

X  “ 

1 

_  x  - 

46  1 

59 

1 

i  _ 

40 

“  + 

1 

_  _i_ 

155 

No  | 

2 

T 

1 

.  X  - 

12 

T 

1 

_  _X  _ 

35  1 

62 

■T" 

1 

_  i  _ 

21 

X 

1 

132 

TOTAL 

6 

T 

18 

T' 

81 

121 

“  X  ~ 

61 

-  X 

287 

CHI-SQUARE  =  8.363 


PROB  VALUE  =  0.079 


V.  Conclusions  and  Recommendations 


Introduction 

This  chapter  summarizes  the  relevant  results  of  the  data 
analysis,  suggests  what  the  implications  of  those  results 
might  be,  identifies  possible  limitations  of  the  study,  and 
makes  recommendations  for  further  research  in  the  area  of 
communication  of  requirements  from  the  user  to  the  SPO 
during  the  ongoing  systems  development  process. 

Relevant  Results 

The  results  of  this  study  showed  that,  as  expected,  most 
of  the  communications  between  the  user  and  the  SPO  are 
conducted  by  phone,  and  that  basket  SPO's  use  the  phone  even 
more  frequently  than  do  single  system  SPO's.  This  more 
frequent  use  of  the  phone  by  basket  SPO's  seems  to  be 
related  to  the  fact  that  more  single  system  SPO's  have  user 
representatives  present,  thus  reducing  the  need  to  call  the 
user’s  headquarters  or  field  units  to  clarify  requirements. 

Surprisingly,  analysis  of  the  data  showed  that  15.8 
percent  of  the  respondents  communicated  with  their  user 
either  less  than  once  a  month  or  never.  On  the  other  end  of 
the  spectrum,  33. 4  percent  communicated  with  their  user  more 
than  ten  times  per  month.  The  majority  of  the  user 
representatives  working  at  ASD,  who  were  contacted, 
reported,  not  unexpectedly,  that  they  communicated  with 
their  respective  SPO’s  on  a  daily  basis.  The  frequency  of 


SPO-initiated  communications  did  not  appear  to  be  related  to 
the  number  of  requirements -related  changes  on  the  program. 

On  the  other  hand,  the  frequency  of  user-initiated  changes 
was  positively  related  to  the  number  of  requirements  changes 
on  a  program. 

The  relationship  between  the  amount  of  informal  versus 
formal  communication  and  the  frequency  users  voiced 
dissatisfaction  was  not  statistically  significant.  This  may 
indicate  that  requirements  problems  will  finally  be  surfaced 
without  regard  for  whether  they  are  surfaced  through  formal 
or  informal  channels.  This  study  does  not  show,  however, 
that  the  problems  will  be  surfaced  in  as  timely  a  manner 
through  formal  channels  as  through  informal  ones.  This 
variable  was  not  considered,  and  no  data  was  collected  on 
it. 

The  frequency  with  which  the  users  voiced  dissatis¬ 
faction  with  requirements  implementation  was  not  statis¬ 
tically  related  to  the  acquisition  experience  level  of  the 
program  manager.  Operational  experience  on  the  part  of  the 
program  manager  was  also  not  related  to  the  frequency  of 
users  expressing  dissatisfaction.  One  likely  explanation 
for  this  unexpected  lack  of  relationship  between  operational 
experience  and  dissatisfaction  is  that  the  measure  of 
dissatisfaction  is  biased,  because  it  is  being  reported  by 
SPO  personnel. 

Niether  physical  separation  of  SPO  and  user  nor  limited 
TOY  funds  were  related  to  any  measure  of  requirements 


communication.  Also,  the  majority  of  respondents  stated 
that  lack  of  TDY  funds  was  rarely  or  never  a  problem. 

AFIT  Systems  100  was  the  only  acquisition  course  which 
was  related  to  the  respondents'  perceived  need  for,  and 
value  of,  a  user  representative  being  permanently  assigned 
to  the  SPO.  This  course  was  also  positively  related  to  the 
respondents'  assessment  of  the  state  of  the  requirements 
communication  process.  If  the  respondents  had  completed 
Systems  100,  they  were  much  more  likely  to  give  an 
assessment  of  'good'  or  'very  good, '  than  if  they  had  not 
taken  the  course. 

Implications 

The  general  concensus,  as  developed  from  the  comments  on 
the  surveys  and  interviews,  of  the  participants  in  this 
study  is  that  more  operational  experience  on  the  part  of  the 
program/project  managers  and  more  acquisition  experience  on 
the  part  of  users  will  positively  influence  the 
communication  of  system  requirements  from  the  users  to  the 
SPO.  The  data  collected,  however,  do  not  bear  this  out.  As 
stated  above  there  was  no  statistical  relationship  between 
the  two.  This  seems  counterintuitive  and  may  be  a  result  of 
the  limitation  discussed  below. 

Therefore  the  major,  and  only  statistically  significant, 
implication  of  this  study  is  that,  possibly,  the  more  people 
involved  in  the  systems  acquisition  process  who  can  be  put 
through  the  AFIT  Systems  100  course,  the  more  positive  will 
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be  the  acceptance  of  user  representation  in  the  SPO’s,  and 
the  more  effective  will  be  the  communication  process. 
However,  this  may  not  be  the  case,  since  the  positive 
relationship  between  Systems  100  and  perceived  need  for  a 
user  representative  which  was  demonstrated  in  Chapter  IV 
does  not  show  that  the  variables  are  causally  related. 
Causality  has  not  been  shown,  but  it  may  be  a  reasonable 
conclus ion. 

Limitations 

In  Chapter  III  the  key  dependent  variable  was  identified 
as  the  effective  communication  of  the  users'  system 
requirements  to  the  SPO,  and  was  operationally  defined  in 
terms  of  the  frequency  of  the  users  voicing  dissatis f action 
to  the  SPO  about  problems  with  system  requirements 
implementation.  This  measure  of  communications  effectiveness 
is  limited  because  of  the  bias  introduced  by  having  program 
management  personnel  report  the  frequency  with  which  the 
iser s  on  their  own  programs  are  expressing  dissatisfaction. 
This  is  true  because  there  is  likely  a  tendency  on  the  part 
some  program  managers  to  understate  the  frequency  which 
-heir  users  are  expressing  dis sa t is t act  ion ,  out  of  a  desire 
t  .  present  themselves  and  their  programs  in  the  best 
possible  Light. 

Also,  as  addressed  in  Chapter  I,  the  data  obtained  were 
self  reported  perceptions  t t  jm  individual  program  management 
personnel  responding  to  the  survey  instrument  at  Appendix  A. 


The  analysis  and  results  should  be  viewed  in  light  of 
these  possible  limitations. 

Recommendations  for  Further  Research 

Further  research  in  this  area  should  be  directed  towards 
identifying  a  good  measure  of  requirements  communications 
between  the  user  and  the  SPO. 

One  area  which  may  yield  useful  information  is  deter¬ 
mining  the  impact  of  the  use  of  informal  versus  formal 
channels  on  not  only  the  success  of  requirements  communi¬ 
cations,  but  also  on  the  program  schedule. 

Finally,  a  study  should  be  conducted  in  which  the 
program  managers '  responses  are  paired  with  their  users  * 
responses  to  see  if  any  significant  differences  exist  in  the 
way  each  group  views  the  process.  A  study  of  this  nature 
might  yield  information  which  could  be  used  to  improve  and 
streamline  the  system  requirements  communication  process. 


DEPARTMENT  OF  THE  AIR  FORCE 

AIR  UNIVERSITY 

AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 
WRIGMT-RATTERSON  AIR  FORCE  BASE  OH  45433<<S<3 


attwo.  LSY  (Capt  Smariga,  AUTOVON  785-6569)  .  .  MAY  !l~ 

tuUJtcr  System  Requirements  Survey  Package  -  USA"  SC!.'  8?-56 


Survey  Participant 


1.  The  communication  of  weapon  system  requirements  from  the 
ultimate  user  to  the  System  Program  Office  CSPO)  is  critically 
important  to  the  successful  development  of  effective  weapon 
systems. 

2.  The  enclosed  survey  is  designed  to  measure  which  factors  in 
the  ongoing  communication  process  between  the  user  of  the  weapon 
system  and  the  3P0  are  most  important,  and  where  potential 
problems  may  be.  The  data  gathered  will  become  part  of  an  AFIT 
research  project  and  may  influence  the  SPO-to-user  communication 
process  if  significant  problems  are  found. 

3.  Please  take  the  time  to  complete  the  enclosed  survey  and 
return  it  in  the  enclosed  envelope  by  22  May  1987. 

4.  Your  participation  is  completely  voluntary,  but  we  would 
certainly  appreciate  your  help.  For  further  information,  please 
contact  Capt.  Russ  Smariga  at  AUTOVON  785-6569. 


'JOHN  DUMOND,  LtCol,  USAF 
'Head,  Department  of  Systems 
Acquisition  Management 
School  of  Systems  and  Logistics 


2  ENCL 

1.  Survey 

2.  Return 
Envelope 


STRENGTH  THROUGH  KNOWLEDGE 
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LJSAF  SCN  87-56 


Field  Survey 
Investigating 

THE  COMMUNICATION  OF  THE  USER’S  REQUIREMENTS 
TO  THE  SYSTEM  PROGRAM  OFFICE  DURING  THE  ONGOING 
SYSTEM  DEVELOPMENT  PROCESS 


Your  responses,  suggestions  and  comments  will  be  completely 
anonymous.  No  attempt  will  be  made  to  identify  any 
individual  responding  to  the  survey. 


Please  respond  as  accurately  and  truthfully  to  each 
question  as  possible. 

Any  overall  comments  on  the  survey  may  be  provided  on 
the  back  of  the  last  page,  or  on  additional  paper. 


Please  keep  the  following  definitions  in  mind  as  you 
complete  the  survey. 

User  -  a  member  a  the  organization  which  will  ultimately 
receive  and  operate  the  system  which  is  being  developed  or 
procured  by  your  System  Program  Office  (SPO)  team. 

Requirement  Change  -  either  a  change  in  the  interpretation 
of  a  requirement  as  stated  in  formal  direction  (PMD,  SON, 
etc.),  or  an  actual  change  in  stated  requirements. 

Contract  Change  -  any  change  to  the  agreement  between  the 
government  and  the  system  development  contractor  which 
results  in  a  change  in  the  requirements  for  the 
deliverable  end  item. 


SPO/User  Communication  Survey 


Please  indicate  your  response  by  circling  the  letter  of  the 
BEST  answer  for  each  question.  Questions  where  more  than 
one  response  is  appropriate  are  so  noted. 

1.  How  would  you  classify  the  SPO  in  which  you  work? 

a.  Single  System  SPO 

b.  Basket  SPO 

c.  I  currently  work  as  a  Systems  Technical  Officer 

d.  I  currently  work  as  a  Program  Element  Monitor 

e.  I  am  not  involved  in  Systems  Acquisition  -  Stop  Now, 
please  return  the  survey  in  the  envelope  provided. 

2.  what  is  the  current  phase  of  your  program?  (Circle  more 
than  one  if  you  manage  programs  which  are  in  different 
phases. ) 

a.  Concept  Exploration 

b.  Demonstration/ Validation 

c.  Full-Scale  Development 

d.  Production/Deployment 

e.  Post  Production/Modification 

3.  What  is  the  estimated  total  cost  (including  production) 
of  the  program(s)  for  which  you  are  responsible? 

a.  Less  than  $100,000 

b.  $  100,000  to  $999, 999 

c.  $1,000,000  to  $29,999,999 

d.  $30,000,000  to  $99,999,999 

e.  $100,000,000  or  more 

4.  Is  the  primary  user  for  which  your  system  is  being 
developed  located: 

a.  Within  the  Continental  United  States  (ConUS) 

b.  Outside  the  Continental  United  States  (OConUS) 

If  the  user  is  located  ConUS,  please  answer  5*6  below, 
otherwise  skip  to  7. 

5.  Is  the  user  located: 

a.  At  the  same  base  as  your  assigned  base 

b.  Within  1000  miles  of  your  assigned  base 

c.  More  than  1000  miles  from  your  assigned  base 


L  T3 


6. 


Is  the  user  a  part  of: 


a. 

SAC 

f. 

AFCC 

b. 

TAC 

g- 

AFLC 

c. 

MAC 

h. 

AFSC 

d. 

ESC 

i. 

Other  (Please  Specify) 

e. 

ATC 

7.  If  the  user  is  located  OContJS,  is  the  user  part  of: 

a.  USAFE 

b.  PACAF 

c.  Other  (Please  Specify)  _ 


8.  Is  the  primary  end  user  of  the  system: 

a.  A  headquarters  (ATC,  TAC,  etc.) 

b.  A  field  unit 

c.  Other  (Please  Specify)  _ 


9.  How  often  do  you  communicate  directly  (by  phone, 
message,  meeting,  etc. )  with  the  user? 

a.  Never 

b.  Less  than  once  a  month 

c.  1-5  times  a  month 

d.  6-10  times  a  month 

e.  More  than  10  times  a  month 


10.  How  frequently  are  your  communications  with  the  user 
conducted  by  phone? 

a.  Never 

b.  Rarely 

c.  Sometimes 

d.  Almost  Always 

e.  Always 


11.  How  frequently  are  your  communications  with  the  user 
conducted  by  official  message  traffic? 

».  Never 
b.  Rarely 

Sometimes 
Almost  Always 
e.  Always 
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How  frequently  are  your  communications  with  the  user 
conducted  by  face-to-face  meetings? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  often  does  the  user  initiate  communications  with 
you? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


Does  the  user  most  often  initiate  communications  by: 
Phone 

Official  Message  Traffic 
Face-to-face  meeting 

Some  other  method  (Please  Specify)  _ 


How  frequently  do  communications  which  the  user 
initiates  concern  some  aspect  of  developing  and/or 
refining  system  requirements? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  do  communications  which  the  user 
initiates  relate  to  some  dissatisfaction  with  system 
requirements  as  they  are  being  implemented,  or  some 
deficiency  perceived  by  the  user’ 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  does  official  message  traffic  to  the 
user,  initiated  by  the  SPO,  have  either  HQ  AFSC  or  HQ 
USAF  as  an  information  (or  joint  action)  addressee? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  does  official  message  traffic  to  the 
user,  initiated  by  the  SPO,  have  the  user's  higher 
headquarters,  e, g.  HQ  USAFE/XPP,  as  an  information  (or 
joint  action)  addressee? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  does  official  message  traffic  from  the 
user  have  HQ  AFSC  or  HQ  USAF  as  an  information  (or 
joint  action)  addressee? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  does  official  message  traffic  from  the 
user  have  the  user's  higher  headquarters  as  an 
information  (or  joint  action)  addressee? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  are  communications  which  the  SPO 
initiates  routed  first  to  HQ  AFSC  (or  HQ  USAF)  and  the 
user's  higher  headquarters  before  the  user  is  directly 
contacted? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  often  has  the  user  expressed  dissatisfaction  with 
the  adequacy  of  system  requirements  implementation? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 

How  frequently  does  the  user's  expression  of  dissatis¬ 
faction  result  in  a  requirement  change  to  the  program? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


How  frequently  do  user  initiated  requirement  changes 
necessitate  contractual  changes? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 


What  is  the  average  cost  to  the  program  incurred  due  to 
user  initiated  changes? 

less  than  $10,000 
$10,000  to  $19,999 
$20,000  to  $49,999 
$50,000  to  $99,999 
More  than  $100,000 


26.  How  frequently  do  user  initiated  requirements  changes 
result  in  saving  money  for  the  program? 

a.  Never 

b.  Rarely 

c.  Sometimes 

d.  Almost  Always 

e.  Always 

27.  How  frequently  does  the  user  first  communicate  his/her 
dissatisfaction  with  requirements  implementation 
through  informal  communication  channels,  versus  formal 
channels? 

a.  Never 

b.  Rarely 

c.  Sometimes 

d.  Almost  Always 

e.  Always 

28.  Over  the  past  year  how  many  user  initiated  requirements 
changes  have  been  implemented  with  which  you  have  been 
involved? 

a.  None 

b.  1-2 

c.  3  -  4 

d.  5-10 

e.  More  than  10 


29.  Does  the  SPO  always  wait  for  formal  direction  from  HQ 
AFSC  before  implementing  user  initiated  requirements 
changes? 

a.  Yes 

b.  No 


30.  If  not,  how  frequently  are  user  initiated  requirements 
changes  held  from  implementation  until  formal  direction 
received? 

a.  Never 

b.  Rarely 

c.  Sometimes 

d.  Almost  Always 

e.  Always 


31.  Is  the  decision  to  withhold  a  change  until  formal 
direction  from  higher  headquarters  is  received  based  on 
the  dollar  value  of  the  change,  or  some  other  factor? 

a.  Dollar  value  of  the  change 

b.  Some  other  factor 

c.  Not  applicable 

32.  If  the  decision  to  withhold  a  change  until  formal 

direction  is  received  is  based  on  a  dollar  amount, 

what  is  the  threshold  dollar  amount? 


Does  your  SPO  have  a  representative  of  the  user 
permanently  assigned  as  a  member  of  the  program  team? 


If  yes,  how  often  has  the  user  representative  been 
effective  at  clarifying  or  expediting  the  clarification 
of  questions  regarding  the  implementation  of 
requirements? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 

If  you  do  not  have  a  user  representative  permanently 
assigned,  do  you  feel  that  having  one  would 
significantly  improve  the  process  of  requirements 
implementation? 


How  frequently  has  the  availability/unavailability  of 
TDY  funding  adversely  affected  the  communication  of 
requirements  from  the  user  to  the  SPO? 

Never 
Rarely 
Sometimes 
Almost  Always 
Always 
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37.  Overall,  do  you  feel  that  communications  between  the 
SPO  and  the  user  have  been: 

a.  Very  Poor 

b.  Poor 

c.  Average 

d.  Good 

e.  Very  Good 

38.  Do  you  feel  that  increased  communications  between  the 
using  command  headquarters  and  the  SPO  would  help  or 
hinder  the  communication  of  system  requirements  to  the 
SPO? 

a.  Help 

b.  Hinder 

c.  Neither  Help  nor  Hinder 

39.  Do  you  feel  that  increased  communications  between  tne 
field  user  and  the  SPO  would  help  or  hinder  the 
communication  of  system  requirements  to  the  SPO? 

a.  Help 

b.  Hinder 

c.  Neither  Help  nor  Hinder 

d.  There  is  no  field  user 

40.  For  which  Product  Division  do  you  work? 

a.  Aeronautical  Systems  Division 

b.  Electronic  Systems  Division 

c.  Space  Division 

d.  Armament  Division 

e.  Aerospace  Medical  Division 
£.  Ballistic  Missile  Office 

g.  Other  (Please  Specify)  _ 


41.  What  is  your  current  rank? 


a. 

2  LT 

b. 

1LT 

c. 

CAPT 

d. 

MAJ 

e. 

LTCOL 

f . 

COL 

What  is  the  highest  academic  degree  you  holi" 


1 


< 

j 

i 

.■ 

« 

■' 


42. 


a. 

b. 

c. 


Bachelor’s  Degree 
Master's  Degree 
Doctoral  Degree 


43.  In  what  field(s)  is(are)  your  degree(s)?  (Check  all 
that  apply.  > 

a.  Electrical  Engineering 

b.  Aeronaut ical/ Aerospace  Engineering 

c.  Mechanical  Engineering 

d.  Other  Engineering  (Please  Specify)  _ 

e.  Business/Management 

f.  Science/Math 

g.  Fine  Arts 

h.  History 

i.  Other  (Please  Specify)  _ 


a.  SPO  Director  > Chief  or.  a  SPO  -  may  be  a  single 
program  manager.  > 

b.  Program  Manager  (Single  manager  of  a  complete  system 

may  have  project  managers  as  subordinates.) 

c.  Project  Manager  (Manager  for  a  system  sub-component.) 

d.  Systems  Technical  Officer 

e.  Program  Element  Monitor 

f.  Deputy  SPO  Director 

g.  Manager  of  several  project  managers  who  each  manage 
separate  projects 

h.  Conf iguration/Data  manager 

i.  Project  engineer 
Test  manager 

k.  Dther  (Please  Specify1  _ 


4  5;.  How  many 

a.  none 

b.  1-2 

c .  3-4 


people  do  you  directly  supervise? 

d.  5-10 

e.  more  than  10 


46.  How  many  years  cumulative  experience  do  you  have  as  a 
program  manager? 

a.  1/2  -  1 

b.  1-2 

c.  3-4 

d.  5-10 

e.  more  than  10 


■  A O ^ A .  * O ■  *  .  • 


71 


O  V 


Have  you  served  an  operational  tour? 

a.  Yes,  in: 

1)  Rated  position 

2)  Maintenance  position 

3)  Missile  operations  position 

4)  Space  operations  position 

5)  Other  (Please  Specify)  _ 

b.  No 

With  respect  to  making  the  decision  to  implement  a 
required  change  on  the  program  with  which  you  are 
related,  would  you  say  that  you: 

a.  Have  no  input  to  the  decision  process 

b.  Have  some  limited  input  to  the  decision  process 

c.  Provide  about  half  of  the  input  on  which  the  decision 
is  based 

d.  Provide  most  of  the  input 

e.  Are  the  final  authority  and  make  the  decision 


Which  of  the  following  Professional  Military  Education 
courses  have  you  completed?  (Circle  all  that  apply. > 

a.  Squadron  Officer  School  (Correspondence) 

b.  Squadron  officer  School  (Residence) 

c.  Air  Command  and  Staff  College  (Correspondence/Seminar) 

d.  Air  Command  and  Staff  College  (Residence) 

e.  Air  War  College  (Correspondence/Seminar) 

£ .  Air  War  College  (Residence) 

g.  Industrial  College  of  the  Armed  Forces 

h.  Other  (Please  Specify)  _ 

Which  of  the  following  Acquisition  Program  Management 
training  courses  have  you  completed?  (Circle  all  that 
apply.  ) 

a.  AFIT  Systems  100 

b.  AFIT  Systems  200 
AFIT  Systems  400 

Systems  Acquisition  School  (Brooks  AFB) 
e.  Defense  Systems  Management  College 

t.  Other  DoD  Program  Management  Course (s)  (Please  Specify) 


g.  Non-DoD  Program  Management  Course(s)  (Please  Specify) 


I 


— — - ^ 


Please  include  any  further  comments  ;n  the  space 
on  additional  paper. 

Thank  you  for  your  time  and  for  the  information  wh»  :r.  / 
have  provided. 


PLEASE  RETURN  THIS  SURVEY  IN  THE  ENVELOPE  PROVIDEL 
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Training  is  hard  to  get  due  to  full  time  work  requirements. 


System  acquisition  varies  .  .  .  because  programs  contracted 

out  have  unstable  funding.  The  key  is  to  maintain  funding  - 
users  cannot  help  with  this. 

Complex?  -  You  bet*  Political?  -  In  spades!! 

There  is  a  reluctance  tor  the  user  to  say  they  don't 
understand  and  also  their  naivete  is  sometimes  exploited 
through  duintoriMtion, 


Problem  is  with  initial  user  requirements  prior  to  contract 
award  The  using  command]  has  failed  ...  to  adequately 
• hink  thr  ,uqh  their  requirement,  and  to  assess  the  technical 

t  ei 5  ,bi  . i ♦  / 


This  „iP'  tui  difficulty  qe*ting  the  user  to  formalize 
requirements  1  >♦ s  t  verbal  juidance,  but  won’t  put  it  in 
w  r  1  *  i  r.  s 


wt.  »-f.  i.:n'  ,iir  »  i  r.  w  *  *  r.  t  pr  .gram  is  an  issue,  it  is 

.*  i< .  i  f  *  r,e  .iPo  who  .s  dissatisfied  because  ot  the  perceived 

w  r  e»  ,t  ?i  ri  .nvefitmefit  t  >a»isty  the  last,  att.e  bit  .1 

’  r,e  iii*i  '  t  requirements.  fhe  general  thrust  becomes  >ne  ot 

if  •  •  .  rig  *  h »  istrs  *  tar  t  l  ,n  wan*  i ng  everything.  we 

« ve  f.eer,  leasnar.,  sue  i  n  reach  cost  ettective 


~  f  ,  r  ~  , 


M  5 

if  k  *  V 
•  w.  •  .  f 

4  {u.f  I  * 


f 

**  ♦ 

s*  a  r>d 

(erf  ,t  mance 

4  ! 

-  4  jfl  . 

fa  I 

•  r  «-  m 

os  *  ;,r  bl  ems 

'  t 

J  **<§  ft  , 

M 

i  ,  »-m£ 

.  r.  it  pr  ur  am 

be',  a  IS  e 

j  I 

•  i  Ji  e  l  *  3 

♦  «  f .  * 

mm  .  • 

•  »pe-  .  f 

t  eg  u  i  r  emeu  *  .. 

r».-  /■ 

f  - 

*  *"  4  )  * 

4 

,  .  e  * 

*  e  (  • 

p-  a  *  i 

4  4  *  * 

Wf.  4  ♦ 

►  4  r 

*  f  . 

-  1  * 

f 

r 

•  »  a*  , 

*  fl  I  .  '  . 

J  0* 

l  «  4  l  w  ; 

f  f, 

i  is  *  h  ** 

•  »  «• 

1 

/  #•  f  - 

f  t  f  .  "  * 

*  .  *  f 

'  f.  »  ‘W#»  t 

* 

..  a  r 

w  J 

I'.  •  4  > 

-  #.  «  * 

4  1  j  •  * 

4  f.  ,  •  4  #  * 

•  ■ 

J  * 

f 

i  f  % 

,•••»!»■  A'  4 

J  i  h  »*  * 

r.  |  l  |i  *n« 

*  l  r 

r 

-  « 

m  |  .  *  e 

r  •<  W  «  r ,  ■  1 

w  * 

/  «  *  w  i  *  f , 

*°*  f  j 

4  f 

at.  J  (i  s  r 

«mm»  r 

[  ^i  i  fir,*-  . 

-  * 

•  V 

f  ~  +  T 

t 

■  *" 

f  * 

M  ,  XX 

*  II  - 

1  /  Ml* 

• 

ri  *  r  •** 

• 

r  »  » 

♦ 

f  ^ 

f  *  e  f  M  * 

***■!  t  , 

4  *  •*  r  i  * 

*  t 

*  '  •-  f  *  M 

.  r  .  4  *  •• 

*  •  •*  4 

•  '  •  ,  re  » 

f  •  »  •* 

J  %  f  i  1  * 

*  + 

»  *  -  I 

4  f  r  *  4  * 

<  «.  * 

j'  *  .  *  ; 

'  ir.  r 

f.  J 

a.  4  * 

•  »  r  » 


*  '  »  -  i 

m  •  *  *■ 


4*  *  4  ’  .  '  4 

j  4  r  1 


i 


r  <  •  f  4  •  4ft  1  .  * 

♦  4  '  I**  *'«*.? 


Consider  using  electronic  mail. 


I  strongly  feel  that  frequent,  complete  communications  would 
solve  an  awful  lot  of  our  problems.  Most  of  the  known 
obstacles  can  be  overcome  -  its  the  surprises  that  kill  us 

I  believe  that  my  operational  flying  experience  (19  years; 
prior  to  being  involved  in  acquisition  management  provided 
me  with  a  keener  insight  and  interpretation  of  the  user's 
SON. 

I  believe  that  having  a  user  representative  would  facilitate 
the  information  flow,  but  would  hinder  the  decision  making 
process  because  it  adds  another  layer  of  bureaucracy. 

SPO's  could  benefit  greatly  from  listening  more  careful!/  t. 
the  testing  community.  They  could  fix  more  problems  earlier 
if  this  were  more  often  the  case. 

Bottom  line:  Systems  must  meet  rea 1  user  requirements  t 
the  system  should  be  trashed. 

Too  much  emphasis  placed  on  PME.  Let  us  do  our  jubs 

^  We  do  not  coordinate  system  requirements  with  field  units, 
th-'-eby  avoiding  confusion  resulting  from  disinformation 
bet >ten  headquarters  and  field  units. 

\ 

T*e _u»«r  most  often  initiates  communications  by  generals 
'/filing  at  each  other. 

A  group  of  sergeants  from  the  field  have  caused  me  tu  Ki . .  » 

forest  in  letter  and  message  traffic  trying  to  'help  me 
with  a  decision. 

The  user  is  reluctant  to  specify  requirements  other  than  .  n 
general  terms. 

♦  The  user  sometimes  hedges  on  signing  up  to  s  pe-- 1 1  i  a  *  i  ri  - 

'Jser  changes  his  mind  frequently  'usually  when  old  p»a/ets 
PCS  and  new  folks  come  on  board*  . 

often  the  user  doesn't  know  how  to  employ  the  system  unt . . 
well  into  the  test  program. 
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Appendix  C:  SAS  Computer  Program 
tor  Data  Analysis 


options  linesize*78; 
pro*'  f  ormat ; 

value  lobtmt  J 


alue  lobtmt  l*'Sinqle  Sys  SPO’ 

2  * ' Basket  SPO’ 
j  * 'Work  as  SYSTO' 

4  » ' Work  as  PEM’ 

5*'Not  Involved’; 
value  spotmt  l»‘5inqle  iys  SPO"  2»'Basket  SPO'; 
alue  phase fmt  1« 'Concept  Exp  Phase' 

.»’Dem/Vai  Phase' 

»  '  FSD  Phase ’ 

4 *’ Product i on  Phase' 

'  = ' P  j$ t  Prod/ Mod ' 

*>  »  ’  Ear  1  y  Mixed  ' 

*  '  Mid  Mixed  ’ 

8  * ’ La te  Mixed ' 

* » ' Mi xed ’ ; 

i  i  je  /s  ♦  fmt  .  than  •  100K  ' 

2  •  ’  1 0  0  K  *99K' 

-  ‘  iM  .'i.  >M' 

4  • 1  ( om  yy .  • 


u*  fmt 


'  10  OK 
'  iM 
'  JOM 


va  i  ue 
•/a  ;  ue 


S -  *  1 uum  or  more 
1-' With  in  ConUS' 


■ ’OConUS’  3- 'Both 


* • ' Same  Base'  2*'Within  lOOOmi’ 
!«‘More  than  lUUOmi’ 


4 

*  *  Near 

»nd  Far  ' : 

/  »  .  .  e 

md  t  fr*  t 

i 

» 

'  User 

1  s 

SAC  ’ 

* 

‘  '  I  s  e  i 

.  u 

TAC  ' 

'  User 

1  3 

MAC  ’ 

4 

• 

'  Os  *  r 

1  3 

ESC' 

9 

'  User 

1  3 

ATC  ’ 

m 

’  User 

1  S 

AFCC  * 

’ 

'  'He r 

1  3 

AFLC  ' 

• 

'User 

1  3 

AFSC  ' 

- 

other  User  ’ 

L 

' ' Mut ip*e 

Users  ’  ; 

t »  1  ue 

**  'on  t  mt 

1 

1 'User 

1  3 

USAFE' 

a 

* ' user 

1  3 

PACAF' 

) 

•'Other  OCONUS  User 

4 

-  ’  Mu  1 1 1 -  User ’ ; 

va  1  ue 

jsi*r  fmt 

1 

- ' User 

1  S 

HQ’ 

•/alue  com fmt 


2  * ’ Field  Unit' 

)»' Other ’ 

4-’HQ  and  Field'; 

1 • ’ Never ’ 

2  « ’ <  Once  a  Month ’ 
3- ’ 15  Times/Mo.  ’ 

4  *  '  6  -  10  Times  a  Mo. 
5 * '  ■  lu  Times  a  Mo. 


value 


value 


respfmt  1* 'Never' 

2® ' Rarely ’ 

3*  *  Sometimes ' 
4®’Almost  Always' 
5® ’ Always ' ; 
methfmt  1  *  *  By  Phone' 

2®’By  Message' 

3 * ’ By  Meeting' 

4* 'Other  Method’ 
5* ’ Multi -Method ’ ; 


value  chngfmt 


va  1  ue 


value 

value 


value 


value 


value 


value 

value 

value 

value 

value 


chngfmt  1  *  '  <-  10K  ’ 

2* ' 10K  -  1 9K  ’ 

3* ' 20K  -  49K ’ 

4  ®  '  50  K  -  99K’ 

5* '  •  100K ' : 
supfmt  1 * ' None ' 

2  *  '  1  -  2  ' 

3  *  ’  3  -  4  ' 

4*  '  -  10  ' 

5* ’ More  Than  10  ’ ; 
yesnofmt  l®'Yes'  2®’No’; 
changfmt  l*’Dollar  Value’ 

2®’Other  Factor’ 

3»'N/A* ; 

poor fmt  l*'Very  Poor’ 

2  * ’ Poor ' 

3® ’ Average ’ 

4® ’ Good ’ 

5® ’Very  Good’; 
hhnfmt  l»'Help’ 

2® ’ Hinder ’ 

3® ’ Neither  ’ ; 
hhnffmt  i*'Help' 

2  « ' Hinder ’ 

3 ® ' Neither  ' 

4®’No  Field  User'; 
divfmt  1 ® ’ ASD '  2®'ESD’  3®’SD’  4®’AD'  5®’AMD’  o=’BMC 

7  ® ’ Other ’ ; 

rankfmt  1«’2LT’  2*’1LT’  3®'CAPT’  4®'MAJ’  5=’LTCOL 
6* ’COL’ ; 

degrfmt  1= ' Bachelor " s '  2 = ’ Mas  ter ” s '  3* ’ Doctoral '  ; 

typefmt  1* ' Eng Lneer ing '  2®’Sci/Math’  3®'Non-Tech’ 
4*’Other'  5® ' Multiple ’ ; 
titlfmt  l»’SPO  Director’ 

2='Pgm  Mgr’ 

3«’Prj  Mgr' 

4* ’SYSTO' 

5* ’ PEM’ 

6® ’ Dep  SPO  Dir’ 

7=’Mgr  Of  Prj  Mgrs ’ 

8* 'Conf ig/Data  Mgr' 

9*’Proj  Engr’ 

10= ’ Tes t  Mgr' 


' CAPT ’  4  * ' MAJ ’ 


’ LTCOL ' 
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i 1  - ’ other ' ; 

value  expfmt  !»’l/2  -  1  yr.  ’ 

2»  ’  1  -  2  * 

3-  ’  3  -  4  ’ 

4-  *5  10’ 

5  »  '  >  10'; 

value  operfrat  l*’Rated’  2  ■  '  Ma  intenanee  '  3-'Missile’  4=’Space' 
5"'Gther  Ops'  6»’None'  7- ’ Mult iple ’ ; 
value  decistmt  l*’No  Input’ 

2»' Some  Input* 

3-’Half  Input’ 

4 ■ ' Mofl  t  Input’ 

5  *  ’  A1 1  Input’; 

value  pmefmt  l"'SOS*  2-'ACSC*  3- ’AWC'  4-'ICAF’ 

5  * ’ SOS  4  AC SC ’  ft  * ’ SOS  4  AWC' 

7* ’SOS  4  LCAF'  8  ■ ’ SOS ,  ACSC,  AWC’ 

9" ’ ALL ’  10  * ' OTHER ’  1 1  * ’ NONE ’ ; 

value  schfmt  1»'SYS100'  2-’SYS200*  3-’SYS400’  4-’DSMC’ 

5  * ’ SYS  100  4  SYS200  '  6-'ALL  SYS'  7-’SYS  4  SAS’ 
8-'SYS  4  DSMC '  9"'SAS  4  DSMC '  lO-'ALL  TYPES’ 

11*’ NON E  *  12"' SAS ’  13*’ MULTI ’  ; 

value  expstmt  l»’OPER’  3" ’NON -OPS’; 
value  statmt  l*‘SYSTO‘  2-’PEM'; 
value  hqfldfmt  1*’HQ'  2»'Field  Unit’; 
data  init; 

infile  real; 

input  spotyp  1  phase  2  cost  3  userloc  4  conusloc  S  usercmd 
6*7  oconuser  8  usertyp  9  comfreq  10  pho  11  mes  12  meet  13 
userint  14  comtyp  15  comreq  16  udissat  17  hqcom  18  uhqcom 
19  ucomhq  20  ucomuhq  21  comhqu  22  disat  23  dischanq  24 
ktrchanq  25  deltcost  26  savings  27  infocom  28  numchanq  29 
formdir  30  chanhoid  31  criteria  32  amount  33-35  userrep 
36  urephlp  37  urneed  38  tdyfund  39  asesment  40  mcomuhq  41 
mcomfld  42  proddiv  43  rank  44  degree  45  degtyp  46  title 
47-48  numsup  49  exp  50  rated  51  decinput  52  sosc  53  sosr 
54  acscc  55  acscr  56  awcc  57  awcr  58  icaf  59  other  60  pme 
61-62  sysone  63  systwo  64  sysfour  65  sas  66  dsmc  67  odod 
68  ondod  69  school  70-71; 

if  l'»rated<»5  then  expsum»l; 
else  if  rated»7  then  expsum«l; 
else  if  rated*6  then  expsum*3; 
if  spotyp*l  then  spo«l; 
else  if  spotyp»2  then  spo«2; 
else  if  spotyp*3  then  staff-1; 
else  if  spotyp-4  then  staff*2; 
if  usertyp=l  then  usrsum*l; 
else  if  usertyp-2  then  usrsum=2; 
label  spotyp- 'Type  of  SPO  or  Job' 
staff"' SYSTO  or  PEM' 
phase" 'Phase  of  Program' 
cost" 'Total  Program  Cost’ 
user loc» 'ConUS  or  OConUS ' 
conusloc» ' Location  of  Conus  User’ 


usercmd* ' Command  of  the  User' 

oconutera 'Command  of  OConUS  User’ 

usertyp- ’ Field  or  Headquarters  User’ 

comfreq* ’ Frequency  of  Communication’ 

pho*'Comm  percentage  by  Phone’ 

mes*'Comm  percentage  by  Message’ 

meet* 'Comm  percentage  by  Meeting’ 

user int* ' Freq  of  User  Initiated  Comm' 

comtyp*’User  Communicates  By' 

comreq»'Comm  Concerning  Requirements' 

udissat* ' Comm  percentage  RE  Dissatisfaction' 

hqcom* ’ Percentage  of  SPO  Comm  addressing  HO' 

uhqcom»'SPO  Comm  addressing  User  HQ’ 

ucomhq*'User  Comm  addressing  HQ' 

ucomuhq* ' User  Comm  addressing  User  HQ' 

comhqu*'SPO  Comm  routed  First  to  HQ' 

disat* ’ Frequency  User  expresses  Dissatisfaction' 

dischang* ’ Perc  of  time  Dissat  results  in  Change' 

ktrchang* ' Perc  of  time  Contractual  Changes  Reqd ' 

deltcost* 'Average  Cost  of  Each  Change’ 

savings* ’ Perc  of  User  Changes  Which  Save  Money' 

infocom* ' Inf ormal  Channels  Are  Used' 

numchang* ' Number  of  Changes  in  Past  Year’ 

formdir*'SPO  Waits  for  Formal  Direction' 

chanhold* ' Perc  of  Changes  Held  for  Formal  Dir' 

criteria* 'Decision  to  Hold  based  on' 

amount* ' Dollar  Amount  of  Criteria’ 

userrep* ' User  Representative  in  SPO?' 

urephlp- ' User  Rep  Effectiveness' 

urneed*'Need  for  User  Rep' 

tdyfund-’ Effect  of  TDY  Funds' 

asesment* 'Assessment  of  Communications’ 

mcomuhq* 'More  SPO  to  User  HQ  Comm' 

mcomf Id* 'More  SPO  to  Field  User  Comm' 

proddiv* ’ Product  Division  Involved' 

rank* 'Rank  of  Respondent’ 

degree* 'Type  of  Degree  held' 

degtyp='Area  of  Specialization' 

title*'Type  of  Position  by  Title' 

nums up* 'Number  of  People  Supervised' 

exp* 'Years  Experience’ 

rated* 'Operational  Experience’ 

decinput* 'Amount  of  Input  Into  Decision  Process' 

sosc='SOS  by  Correspondence' 

sosr='SOS  in  Residence' 

acscc*'ACSC  by  Correspondence' 

acscr*'ACSC  in  Residence' 

awcc='AWC  by  Correspondence' 

awcr*'AWC  in  Residence' 

icaf* ' Industrial  College  of  the  Armed  Forces' 
other* 'Other  PME ' 
pme='PME  Summary' 
sysone* 'Systems  100' 


systwo* ' Systems  200' 
sys four* ' Systems  400' 
sas*'Systems  Acquisition  School’ 
dsmc* 'Defense  Systems  Management  College' 
odod»’Other  DoD  Pgm  Mgt  Courses’ 
ondod*' Other  Non-DoD  Pgm  Mgt  Courses’ 
school* ' Acquis  it ion  Educ  Summary’ 
exps urn- 'Summary  of  Operational  Exp’ 
spo*’Single  System  or  Basket  SPO' 
usrsum*'Hq  and  Field  Units’; 

format  spotyp  jobfmt.  phase  phasefmt.  cost  costfmt.  userioc  ioctmt. 
conusloc  dlocfmt.  usercmd  cmdfmt.  oconuser  ocontmt.  usertyp 
userfmt.  comfreq  comfmt.  pho  mes  meet  userint  comreq  dissat 
hqcom  uhqcom  ucomhq  ucomuhq  comhqu  disat  dischang  ktrchang 
savings  infocom  chanhold  urephlp  tdyfund  resptmt.  comtyp 
methfmt.  deltcost  chngfmt.  comtyp  methrmt.  mcomuhq  hnntmt. 
mcomfld  hhnffmt.  numchang  numsup  supfmt.  criteria  rhangtmt. 
asesment  poorfmt.  proddiv  divfmt.  rank  rankfmt.  degree 
degrfmt.  degtyp  typefmt  title  titlfmt.  exp  exptmt.  rated 
operfmt.  decinput  decistmt.  formdir  userrep  urneed  sosc  soar 
acscc  acscr  awcc  awcr  leaf  other  sysone  systwo  sysrour  sas 
dsmc  odod  ondod.  yesnotmt.  pme  pmefmt.  achooi  schtmt.  expsum 
expsfmt.  spo  spofmt.  usrsum  hqfldtmt.; 
proc  freq; 

tables  spotyp  --  usrsum; 

tables  spo* (comfreq  pho  mes  meet  comreq  udissat  disat 
savings  infocom  comtyp  asesment >  /  chisq 
nocol  norow; 

tables  pho* (phase  comfreq  decinput)  /  chisq  nocol  norow: 
tables  userint* ( comfreq  pho  mes  meet  udissat)  chisq 
nocol  norow; 

tables  comtyp*user ioc  chisq  nocol  norow; 

tables  numchang • i comfreq  comreq  disat  dischang  xtrtnanq 

formdir)  ,  chisq  nocol  norow; 
tables  amount ‘oconuser  chisq  nocol  norow; 
tables  userrep* ( spo  usercmd)  /  chisq  nocol  norow; 
tables  urneed* » usercmd  disat  urephlp  userrep  mcomtid 

/  chisq  nocol  norow; 

tables  tdyfund* ( conus ioc  pho  urneed)  chisq  nocol  nor jw; 
tables  asesment*  oconuser  comtreq  pho  meet  mes  urneeu  user..-. t 

i  chisq  nocol  no row; 

tables  rank*comfreq  ,  chisq  nocol  norow; 

tables  comf req •( degree  rated  expsum  decinput  sysone  systw. 


sys tour  sas  expsum)  chisq  nocol  norow; 
tables  uhqcom*hqcom  /  chisq  nocol  norow; 
tables  ucomhq* < hqcom  uhqcom)  /  chisq  nocol  norow; 


tables  disat *< comreq  udissat  infocom  spo»  chisq  norow  n 
tables  dischanq* < ktrchanq  sas>  /  chisq  nocol  norow; 
tables  chanhold* formdir  /  chisq  nocol  norow; 
tables  mcomuhq*savings  /  chisq  nocol  norow; 
tables  decinput*formdlr  /  chisq  nocol  norow; 
tables  school *( di sat  udissat  comfreq  pho  mes  meet 

asesment  formdir  dischang  infocom  urephlp 
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urneed)  /  chisq  nocol  norow; 
tables  urephlp* < userrep  asesroent)  /  chisq  nocol  norow; 
tables  sysone'urneed  /  chisq  nocol  norow; 
tables  title*proddiv  /  chisq  nocol  norow; 
tables  numchanq* ( comfreq  userint)  /  chisq  nocol  norow; 


USING  COMMAND  SYSTEMS  OFFICER  GUIDED  INTERVIEW  FORM 


The  data  gathered  in  this  guided  interview  will  support  an 
AFIT  research  project  dealing  with  the  communication  of 
system  requirements  from  the  User  to  the  System  Program 
Office  (SPO).  Results  of  the  project  will  be  published  in  an 
AFIT  Thesis. 


Please  answer  each  question  as  candidly  and  honestly  as 
possible.  Any  additional  information  or  comments  which  you 
think  may  be  helpful  may  be  included  on  the  attached  page, 
or  on  additional  paper. 


Participation  is  completely  VOLUNTARY.  Results  will  be 
published  in  composite  form  only.  No  attempt  will  be  made 
to  identify  any  individual  respondant.  All  responses  will 
be  taken  ANONYMOUSLY. 


Thank  you  for  your  cooperation! ! l 


1.  Are  you  involved  with  the: 

a.  MACSO 

b.  SACSO 

c.  TACSO 

d.  Other  (Please  Specify)  _ 

2.  What  is  your  current  rank?  _ 

3.  How  long  have  you  been  in  your  current  position? 

a.  <  lyr 

b.  1  -  2yrs 

c.  3  -  4yrs 

d.  5yrs  or  more 

4.  In  what  phase  is  (are)  the  program(s)  with  which  you 
work? 

a.  Concept  Exploration 

b.  Demonstration/Validation 

c.  Full  Scale  Development 

d.  Production/Deployment 

e.  Post-Production/Modification 

5.  In  what  phase  was  the  program  when  you  first  assumed 
your  current  position? 

a.  Concept  Exploration 

b.  Dem/Val 

c.  FSD 

d.  Prod/Dep 

e.  Post-Prod/Mod 


6. 


How  often  do  you  meet  with  personnel  from  the  using 
command  which  you  represent  to  discuss  program 
requirements  ? 

a.  Never 

b.  <  Once  a  month 

c.  1-2  times/month 

d.  3-5  times/month 

e.  >5  times/month 

7.  When  you  meet  with  personnel  from  the  command  which  you 
represent  are  they  most  often  from: 

a.  Headquarters/Staff  level 

b.  Numbered  Air  Force  level 

c.  Wing  level 

d.  Squadron/Unit  level 

8.  Was  your  previous  assignment  related  to  the  mission  area 
of  the  program* s)  with  which  you  are  currently  involved? 

a.  Yes 

b.  No 

If  yes,  in  what  way? _ 


9.  Have  you  worked  in  any  acquisition  related  position 
prior  to  this  assignment? 

a.  Yes,  as  a  _ 

with  an  AFSC  of  _ . 

b.  No 

10.  Check  each  of  the  following  acquisition  courses  which 
you  have  had. 

a.  AFIT  Systems  100 

b.  AFIT  Systems  200 

c.  AFIT  Systems  400 

d.  Systems  Acquisition  School  at  Brooks  AFB 

e.  Defense  Systems  Management  College 

f.  Other  Courses  _ _ 

g.  None 

11.  Do  you  feel  that  more  operational  experience  on  the 
part  of  the  Program  Managers  in  the  SPO  would  enhance 
communication  of  requirements  from  the  User  to  the  SPO? 

a.  Yes 

b.  No 

12.  Do  you  feel  that  more  acquisition  training  on  the  part 
of  the  User  would  enhance  communication  of  requirements 
from  the  User  to  the  SPO? 

a.  Yes 

b.  No 
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13.  Do  you  feel  that  nor«  acquisition  axparianca  on  tha 
part  of  tha  Usar  would  anhanca  communication  of 
raquiramants  from  tha  Usar  to  tha  SPO? 

a.  Yas 

b.  No 

14.  What  do  you  faal  is  tha  biggest  problam  (if  thara  is 
ona)  with  tha  cosimunication  of  raquiramants  from  Usar 
to  SPO"> 

a.  Schaduia  prassura 

b.  Lack  of  oparational  axparianca  on  tha  part  of  the 
Program/ Pro ject  managers 

c.  Overall  lack  of  axparianca  of  Program/Pro jact  managers 

d.  Lack  of  acquisition  experience  on  the  part  of  the  'Jser3 

e.  Other  _ _ 

15.  other  comments: 


Appendix  E:  Selected  Comments  £rom 
User  Representatives 


The  user  needs  the  system  immediately  and  perceives  the 
acquisition  process  as  too  slow  and  unresponsive.  In 
several  cases  the  needed  system  is  not  fielded  for  5-7  years 
and  occasionally  not  even  in  the  same  decade.  In  the  ECM 
field  against  our  primary  adversary  this  guarantees 
acquisition  of  antiquated  resources  to  counter  historically 
obsolete  threats.  In  this  light  I  believe  the  primary  cause 
of  poor  communications  between  the  user  and  SPO  is  the 
result  of  both  organizations  striving  to  accomplish  their 
missions  utilizing  an  over  regulated,  highly  restrictive, 
bureaucratic  structure  that  stifles  initiative  and  retards 
acceptable  progress. 

Only  takes  a  short  (month  or  two)  period  of  time  for 
operationally  experienced  users  to  learn  how  the  acquisition 
process  works. 

Eliminate  ASD  and  let  the  User  acquire  his  own  weapon 
systems . 

More  acquisition  training  on  the  part  of  the  user  would  aid 
in  communications,  but  probably  not  enough  to  make  a 
difference. 

More  acquisition  experience  on  the  part  of  the  user  would 
aid  in  communication,  but  you  can't  be  everything  in  a 
career  and  still  progress. 

With  manning  levels  critical  in  operations,  its  hard  to  [get 
more  acquisition  experience  and  training!. 

CThe  biggest  problem  with  the  requirements  communications 
process  is  the]  misunderstanding,  perhaps  from  lack  of 
experience  of  users  on  how  acquisition  system  works. 

I  never  meet  face  to  face  with  people  from  HQ  TAC  (or  very 
rarely,  i.e.  once  a  year).  However,  we  do  speak  on  the 
phone  anywhere  from  1  to  10  times  a  month,  depending  on  the 
program.  I  deal  with  people  at  the  Headquarters/Staff  level. 

I  appear  to  be  an  odd  case,  since  TACSO  is  my  first 
assignment:  I  have  no  operational  experience  to  offer  the 
acquisition  community.  All  I  do  is  act  as  an  intelligent 
messenger  for  HQ  TAC. 

In  my  opinion,  the  ability  to  write,  speak,  read,  and  think 
clearly  and  logically  are  the  first  things  necessary  to 
communicate  requirements.  That  may  seem  obvious,  but  it  is 
lacking  in  the  acquisition  community  particularly. 


Better  communication  may  help  the  user  and  acquisitioneer 
understand  each  other  better  and  get  along  better,  but  I 
doubt  it  will  improve  the  acquisition  process  as  a  whole. 

At  best  it  will  make  our  jobs  easier,  because  we  wouldn't 
have  to  shout  so  loud  to  make  the  acquis itioneers  understand 
why  we  need  the  system  now,  and  he  wouldn't  have  to  shout  so 
loud  to  make  us  understand  that  the  contractor  is  not 
producing  as  expected,  as  is  typically  the  case. 

Training  would  not  help  the  requirements  process,  but  would 
help  HQ  users  work  more  harmoniously  with  the  SPO  by 
understanding  the  acquisition  process,  problems, 
frustrations,  etc. 

CSPO's  need  to]  understand  that  requirements  do  change  and 
flexibility  in  acquisition  is  required.  Avoid  accusations 
of  "gold  plating. ”  If  requirements  are  overstated,  work 
with  the  user  to  resolve. 

The  biggest  problem  with  the  communication  of  requirements 
is  lack  of  user  discipline! 

I  could  use  more  operational  experience! 

Until  they  have  been  working  in  the  acquisition  arena  for  an 
extended  period,  users  (flyers)  have  an  extremely  difficult 
time  with  simply  understanding  acquisition  jargon  (acronyms, 
technical  terms,  etc.). 

[User]  Requirements:  -  Faster  Horses 

-  Stronger  Whiskey 

-  Younger  Women 

SPO  Interpretation:  -  Speed  up  the  Merry-Go-Round 

-  Get  a  'Shirley  Temple'  Double 

-  Recruit  Pre-School  Ballerinas 
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Block  19.  Abstract. 

Air  Force  acquisition  program  management  officers  were  surveyed  to 
determine  vrt\ich  factors  in  the  user  to  system  program  office  requirements 
communication  process  were  related  to  achieving  effective  communication. 
Using  command  representatives  working  at  Aeronautical  Systems  Division 
were  also  contacted  to  provide  their  perspective  of  the  communications 
process.  Results  obtained  from  reading  the  comments  on  the  questionnaires 
and  from  the  interviews  indicated  that  both  program  managers  and  user 
representatives  believed  that  additional  operational  experience  on  the 
part  of  acquisition  management  personnel  would  enhance  the  requirements 
communication  process.  The  analysis  of  the  data,  however,  did  not  support 
this.  Operational  experience  of  the  program  manager  was  not  statistically 
related  to  any  of  the  measures  of  successful  communications. 

Program  managers  who  had  completed  AFIT  Systems  100  tended  to  have  a 
more  positive  outlook  on  both  the  desirability  of  having  a  user  represen¬ 
tative  in  the  SPO,  and  of  the  overall  requirements  communication  process. 
This  relationship  was  not  present  for  any  other  single  acquisition 
management -re la ted  course. 

The  results  indicate  that  no  single  factor  contributes  significantly 
to  the  success  or  failure  of  the  systems  requirements  communication 
process . 
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